Ship Mints <shipmints@gmail.com> writes:
> On Wed, Mar 26, 2025 at 9:00 AM Dmitry Gutov <dmitry@gutov.dev> wrote:
>
>> On 26/03/2025 13:48, Ship Mints wrote:
>> > On Tue, Mar 25, 2025 at 11:11 PM Dmitry Gutov <dmitry@gutov.dev
>> > <mailto:dmitry@gutov.dev>> wrote:
>> >
>> > On 25/03/2025 17:42, Ship Mints wrote:
>> > > I just got bitten by project-buffers not reporting all the buffers
>> > > "strictly" related to the project because project.el thinks there
>> > are
>> > > two different projects. I can't imagine that me and the
>> > colleagues of
>> > > mine that use convenience symlinks are the only ones to see these
>> > kinds
>> > > of inconsistencies. Just thought I'd leave a concrete example in
>> > this
>> > > thread.
>> >
>> > Thanks for the example.
>> >
>> > > I've turned my advice back on to force truename canonicalization
>> > for the
>> > > time being.
>> >
>> > Does that change really help?
>> >
>> >
>> > It does for unifying project-name and project-root.
>>
>> Do they have corresponding scenarios that cause confusion?
>>
>> > In my testing, what it results in, is showing only the buffers
>> > belonging
>> > to the "canonical" project, both when project-switch-buffer is called
>> > when in it, or when inside a "symlinked" version. Buffers visited
>> from
>> > the "symlinked" project are not suggested in completion anymore.
>> >
>> > When reproducing, try using find-file (C-x C-f) to open the buffers.
>> >
>> >
>> > Yes, indeed, project-buffers also needs some help.
>>
>> We could add a user option for project-buffers specifically, as one
>> approach.
>>
>
> I assume this would be the same option that canonicalizes project-roots so
> it's all synchronized.
>
>> Thanks for the continuing discussion.
>> >
>> > WRT projectile, having only eyeballed the code (I haven't used it), it
>> > seems truename use is not optional. It looks like projectile-project-
>> > buffer-p is defined in terms of truename https://github.com/bbatsov/
>> > projectile/blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/
>> > projectile.el#L1775 <https://github.com/bbatsov/projectile/
>> > blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/
>> > projectile.el#L1775>, project-root caches the truename (but I see a bug
>> > in the code which doesn't normalize dir on the way in so users likely
>> > get odd results) https://github.com/bbatsov/projectile/
>> > blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/projectile.el#L1385
>> > <https://github.com/bbatsov/projectile/
>> > blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/projectile.el#L1385>, the
>> > file cache is in terms of truename https://github.com/bbatsov/
>> > projectile/blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/
>> > projectile.el#L1262 <https://github.com/bbatsov/projectile/
>> > blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/projectile.el#L1262>. </>
>>
>> I wonder how it affects Projectile's performance over Tramp.
>>
>
> No idea. But I can say that I have wrapped a bunch of project.el functions
> to avoid remote file operations based on a personal user option (some of my
> users are heavy Trampers, some hosts are slow). But the way I've done it
> is a blanket inhibition, not project-specific or some other appropriate
> criteria which would be nicer. Perhaps a .project.eld file with variables
> akin to dir-locals that project could consult. I haven't had the time to
> think that through.
>
> I've also implemented personal 'consult' project and related
> buffer-matching functions to handle project root canonicalization. Those
> functions are not in terms of project-buffers and perhaps should be as they
> miss out on back-end specializations. I've started a discussion in the
> consult repo to offer to contribute PRs over there.
I'm not unsympathetic to the need, but I think we need to understand
whether your request is project-specific or not. I realized that the
Emacs features I wanted already exist. In particular,
find-file-visit-truename should excise symlinks from every visited path,
and directory-abbrev-alist should be able to alias one directory
to another. Can you add your symlink directory to
directory-abbrev-alist and have it rewritten to the truename?
Of course people can always hack around these cases manually.
To me, what makes project.el special is that it has an implicit promise to organize buffers related to a project. That the existing implementation depends on the ambient directory from which a file buffer was created to determine what's related has become a "leaky abstraction" where symlinks to projects are involved. The documentation in project.el kind of alludes to this limitation in an implied way for transient projects. It is silent on directory assumptions for vc projects, instead delegating to the vc back end.
It would benefit the whole community to offer a resolution to let project.el fulfil its buffer organization mission independent of convenience names and that doesn't rely on management of directory-abbrev-alist (eek).