bug#72611: [Patch] Store canonical paths to project roots

bug#72611: [Patch] Store canonical paths to project roots

[Brad Howes via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 1635 bytes --]

Tags: patch

Adapt 'project-roots' to always return a canonical path
in order to eliminate aliased values in the saved project
paths file.

In GNU Emacs 29.4 (build 2, aarch64-apple-darwin24.0.0, NS
 appkit-2559.10 Version 15.0 (Build 24A5298h)) of 2024-07-27 built on
 brh-pro-1.home
Windowing system distributor 'Apple', version 10.3.2566
System Description:  macOS 15.0

Configured using:
 'configure --disable-dependency-tracking --disable-silent-rules
 --enable-locallisppath=/opt/homebrew/share/emacs/site-lisp
 --infodir=/opt/homebrew/Cellar/emacs-plus@29/29.4/share/info/emacs
 --prefix=/opt/homebrew/Cellar/emacs-plus@29/29.4 --with-xml2
 --with-gnutls --with-native-compilation --without-compress-install
 --without-dbus --without-imagemagick --with-modules --with-rsvg
 --with-ns --disable-ns-self-contained 'CFLAGS=-Os -w -pipe
 -mmacosx-version-min=15
 -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk -O2
 -DFD_SETSIZE=10000 -DDARWIN_UNLIMITED_SELECT'
 'CPPFLAGS=-I/opt/homebrew/opt/zlib/include
 -I/opt/homebrew/opt/jpeg/include -I/opt/homebrew/opt/icu4c/include
 -I/opt/homebrew/opt/sqlite/include -I/opt/homebrew/opt/readline/include
 -isystem/opt/homebrew/include -F/opt/homebrew/Frameworks
 -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk'
 'LDFLAGS=-L/opt/homebrew/opt/zlib/lib -L/opt/homebrew/opt/jpeg/lib
 -L/opt/homebrew/opt/icu4c/lib -L/opt/homebrew/opt/sqlite/lib
 -L/opt/homebrew/opt/readline/lib -L/opt/homebrew/lib
 -F/opt/homebrew/Frameworks -Wl,-headerpad_max_install_names
 -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk
 -L/opt/homebrew/opt/libgccjit/lib''


[-- Attachment #2: 0001-Always-return-canonical-paths.patch --]
[-- Type: application/octet-stream, Size: 881 bytes --]

From 8733c5cd69d57106c0e3038cc55427d3ca888c1d Mon Sep 17 00:00:00 2001
From: Brad Howes <bradhowes@mac.com>
Date: Tue, 13 Aug 2024 21:11:45 +0200
Subject: [PATCH] Always return canonical paths

---
 lisp/progmodes/project.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index 3d0f742c51d..af6cf4640d1 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -266,7 +266,7 @@ project-root
 (cl-defmethod project-root (project
                             &context (project--within-roots-fallback
                                       (eql nil)))
-  (car (project-roots project)))
+  (expand-file-name (car (project-roots project))))
 
 (cl-defgeneric project-roots (project)
   "Return the list containing the current project root.
-- 
2.39.4 (Apple Git-150.1)

bug#72611: [Patch] Store canonical paths to project roots

[Eli Zaretskii]

> Date: Tue, 13 Aug 2024 21:56:38 +0200
> From:  Brad Howes via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> Tags: patch
> 
> Adapt 'project-roots' to always return a canonical path
> in order to eliminate aliased values in the saved project
> paths file.

Dmitry, any comments?

bug#72611: [Patch] Store canonical paths to project roots

[Dmitry Gutov]

Hi!

On 13/08/2024 22:56, Brad Howes via Bug reports for GNU Emacs, the Swiss 
army knife of text editors wrote:
> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
> index 3d0f742c51d..af6cf4640d1 100644
> --- a/lisp/progmodes/project.el
> +++ b/lisp/progmodes/project.el
> @@ -266,7 +266,7 @@ project-root
>   (cl-defmethod project-root (project
>                               &context (project--within-roots-fallback
>                                         (eql nil)))
> -  (car (project-roots project)))
> +  (expand-file-name (car (project-roots project))))

This is the default implementation of 'project-root' which is currently 
only used as a fallback when a backend implements the outdated 
convention (method 'project-roots').

So it might have effect in your case (which backend are you using? I'd 
like to ask), but not in the general one.

Speaking of "saved project paths file", if your goal is to have expanded 
file names written to ~/.emacs.d/projects, then we have code in 
project--remember-dir that explicitly abbreviates, since August 2023. 
That's commit 255b7e1a046c.

Perhaps if your Emacs and project.el are older, you don't see it yet.

bug#72611: [Patch] Store canonical paths to project roots

[Brad Howes via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On 26 Aug 2024, at 03:20, Dmitry Gutov <dmitry@gutov.dev> wrote:
> 
> This is the default implementation of 'project-root' which is currently only used as a fallback when a backend implements the outdated convention (method 'project-roots').
> 
> So it might have effect in your case (which backend are you using? I'd like to ask), but not in the general one.
> 
> Speaking of "saved project paths file", if your goal is to have expanded file names written to ~/.emacs.d/projects, then we have code in project--remember-dir that explicitly abbreviates, since August 2023. That's commit 255b7e1a046c.

Hi Dimitri,

Thanks for the info. I see now my patch is not the proper place in which to do such a change, so I will withdraw it and close it.

FYI, my goal was to keep from seeing duplicate entries in the list of projects due to one path starting with “~” and another having that expanded out to my home directory. Ideally the paths would all be shortened by removing their common prefix, but I took the shortest route and just expanded whatever was obtained from 

As for a backend, I assume that this is being delegated to ‘vc’ or ‘git’. Not really sure, but I don’t think I’ve set anything specific for this.

Regards,

Brad

bug#72611: [Patch] Store canonical paths to project roots

[Dmitry Gutov]

On 26/08/2024 20:33, Brad Howes wrote:
> FYI, my goal was to keep from seeing duplicate entries in the list of
> projects due to one path starting with “~” and another having that
> expanded out to my home directory. Ideally the paths would all be
> shortened by removing their common prefix, but I took the shortest route
>   and just expanded whatever was obtained from

It would be useful to track down the scenario which creates those 
different paths.

You might want to upgrade to the last version of 'project' first and 
re-test (in 'M-x list-packages'), if you don't already have it installed.

IIRC project--read-project-list's current definition (with its 
`abbreviate-file-name' calls) is exactly an effort to avoid that.