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