GNU bug report logs - #77122
[PATCH] project--find-in-directory resolves symlinks

Previous Next

Full log

Message #104 received at 77122 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 77122 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Daniel Colascione <dancol <at> dancol.org>
Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks
Date: Wed, 26 Mar 2025 15:00:16 +0200

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.

> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.