Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks

From: Ship Mints <[email-masked]>
Date: Thu, 27 Mar 2025 10:41:22 -0400

On Wed, Mar 26, 2025 at 8:28 PM Daniel Colascione <[email-masked]> wrote:

> Ship Mints <[email-masked]> writes:
>
> > On Wed, Mar 26, 2025 at 9:00 AM Dmitry Gutov <[email-masked]> wrote:
> >
> >> On 26/03/2025 13:48, Ship Mints wrote:
> >> > On Tue, Mar 25, 2025 at 11:11 PM Dmitry Gutov <[email-masked]
> >> > <mailto:[email-masked]>> 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).