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

Previous Next

Full log

Message #116 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: Thu, 27 Mar 2025 11:22:22 -0400

On March 27, 2025 10:41:22 AM EDT, Ship Mints <shipmints <at> gmail.com> wrote:
>On Wed, Mar 26, 2025 at 8:28 PM Daniel Colascione <dancol <at> dancol.org> wrote:
>
>> 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?
>>
>
>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).


I hear you, but I'm not sure the situation is so clear cut. Of course we want a single project in the user's mind to map to one process object on the Emacs heap: there's just genuine diversity in opinions of what counts as "the same" and I think project is the wrong level of abstraction for expressing your desired unification. We already have a way for the use to express a preference that the fully resolved name of a file be considered its identity, and we already have a mechanism through which the user can inform Emacs of the canonical version of an ambiguous path.

Maybe we can improve the UX. When we find ourselves with two project objects (say A and B) that refer to the same true path, we can ask the user to choose between making A canonical, making B canonical, and rejecting the unification --- then remember that choice in the existing mechanism. That'll fix the non-project path ambiguity problems too.

Previous Next

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