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

Previous Next

Full log

Message #29 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>
Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks
Date: Mon, 24 Mar 2025 06:40:29 -0400

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

On Sat, Mar 22, 2025 at 9:47 PM Daniel Colascione <dancol <at> dancol.org> wrote:

> Dmitry Gutov <dmitry <at> gutov.dev> writes:
>
> > Hi!
> >
> > On 19/03/2025 18:55, Ship Mints wrote:
> >> This avoids duplicate projects accessed via symlinks that share
> >> resolved directory locations.  This has bothered me for a while, so
> >> here we go.
> >
> > Could you describe the reasons why your setup is the way it is?
> >
> > Personally, I've never used symlinks at this level, and if I did, I'm
> > not sure I would see the problem with project-root returning different
> > strings for those.
> >
> > What exactly is the problem? Having the "same" project multiple times
> > in project history?
> >
> > I can name a couple of (probably minor) downsides:
> >
> > * The project detection would be slower (more disk I/O).
> > * project-root would more often return a string that is not a parent
> >   directory of default-directory. Some code out there probably
> >   soft-depends on that.
>
> FWIW, I sometimes symlink convenient names to inconvenient ones, and it
> would be a shame to use the inconvenient names due to excessive
> symlink chasing. (Other packages aren't great about this.) Can't people
> who want symlink chasing add something to project-find-functions?
>

Yeah, good question.  "Can't people" applies pretty much to every feature
and option added to Emacs that people can do themselves including
overriding functions wholesale.  The bigger picture, to me, is that if we
add options to do things like this for our users, then we can help more of
them, we can refine implementations at deeper levels should we need to, we
can prompt people to think more considerately about their working
environments.  Perhaps some never considered using symlinks as vanity paths
and they'll have the choice to treat project objects among those
paths canonically.

Since I suggested it be optional, it would be off by default, right?  If
you think you'd want to canonicalize paths to project roots in some places
and not others, perhaps we could contrive a project sentinel file ala
.project-notruename.el/d or .project-config.el/d, and for people that want
to do things in code, a list project can consult.

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