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

From: Ship Mints <[email-masked]>
Date: Wed, 26 Mar 2025 11:52:26 -0400

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.