GNU bug report logs -
#77122
[PATCH] project--find-in-directory resolves symlinks
Previous Next
Full log
Message #107 received at 77122 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, Mar 26, 2025 at 9:00 AM Dmitry Gutov <dmitry <at> gutov.dev> wrote:
> On 26/03/2025 13:48, Ship Mints wrote:
> > On Tue, Mar 25, 2025 at 11:11 PM Dmitry Gutov <dmitry <at> gutov.dev
> > <mailto:dmitry <at> 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.
[Message part 2 (text/html, inline)]
This bug report was last modified 109 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.