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

Previous Next

Full log

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

From: Ship Mints <shipmints <at> gmail.com>
To: Daniel Colascione <dancol <at> dancol.org>
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 12:04:25 -0400

[Message part 1 (text/plain, inline)]

On Thu, Mar 27, 2025 at 11:22 AM Daniel Colascione <dancol <at> dancol.org>
wrote:

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


I don't think it matters to me which A or B (or C or D) becomes the
"master" but I'd still prefer the master to be rooted in the true path.
The one that gets recorded in projects.eld, I think should be the master
and if we have a user option where the true name always becomes master,
that's cool.

If we're willing to prompt, then we'd be willing to have a user option to
default to a selection and not prompt.  That would be fine with me.

[Message part 2 (text/html, inline)]

Previous Next

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