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

Previous Next

Full log

View this message in rfc822 format

From: Ship Mints <shipmints <at> gmail.com>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 77122 <at> debbugs.gnu.org
Subject: bug#77122: [PATCH] project--find-in-directory resolves symlinks
Date: Thu, 20 Mar 2025 07:19:10 -0400

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

On Wed, Mar 19, 2025 at 10:15 PM Dmitry Gutov <dmitry <at> gutov.dev> wrote:

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

Many of us here do the same out of habit and convenience to normalize our
own directory trees as an overlay on the varied-structured work we need to
deal with.

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

If one loads two files from the same project but one via the symlinked
path, and another via the natural path (often, an underlying tool will
choose natural while Emacs chooses default-directory), and one has tools
that compare project-likeness between/among buffers, they report different
projects.  That's misleading and annoying.


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

I've been running with the following for a while and haven't found any
issues yet, hence the patch to help others with similar situations.

  (defun my/project--find-in-directory-advice (args)
    (cons (file-truename (car args)) (cdr args)))
  (advice-add #'project--find-in-directory :filter-args
#'my/project--find-in-directory-advice)

We can make this a user option nil (default), t (always), 'inhibit-remote
so the user can avoid hammering remote connections.  If we could normalize
at a lower level and still retain the symmetry between default-directory
and a normalized project object, that would suggest caches like the one in
project-try-vc have to cache more than one project directory form.  Doesn't
seem worth the complexity?

-Stephane

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