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

Previous Next

Full log

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

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

Ship Mints <shipmints <at> gmail.com> writes:

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

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?

Previous Next

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