GNU bug report logs - #64088
[PATCH] Make project-root for vc projects return an absolute path

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#64088: closed ([PATCH] Make project-root for vc projects
 return an absolute path)
Date: Wed, 23 Aug 2023 00:25:01 +0000

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

Your message dated Wed, 23 Aug 2023 03:24:02 +0300
with message-id <3d4d2e2c-0ed1-6998-694d-dcc08b2ec837 <at> gutov.dev>
and subject line Re: bug#64088: [PATCH] Make project-root for vc projects return an absolute path
has caused the debbugs.gnu.org bug report #64088,
regarding [PATCH] Make project-root for vc projects return an absolute path
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
64088: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64088
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Make project-root for vc projects return an absolute path
Date: Thu, 15 Jun 2023 16:48:05 -0400

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

Tags: patch


Before this, if a vc project was in the user's home directory,
project-root would be "~/some/path".  This violates the spec of
project-root, which requires an absolute path.  One concrete bug
caused by this is that (project-forget-project "~/some/path") would
work but (project-forget-project "/home/user/some/path") would not.

I ran into this while trying to use file-notify to automatically
discover and forget projects.  file-notify returns truly absolute paths,
so I ran into the aforementioned concrete bug.

In GNU Emacs 29.0.90 (build 8, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.15.12, Xaw scroll bars) of 2023-06-04 built on
 igm-qws-u22796a
Repository revision: 11d76029db5f0d9e016f247aac24dd430b729c2a
Repository branch: emacs-29
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: CentOS Linux 7 (Core)

Configured using:
 'configure --with-x-toolkit=lucid --with-gif=ifavailable'

[0001-Make-project-root-for-vc-projects-return-an-absolute.patch (text/patch, attachment)]

[Message part 5 (message/rfc822, inline)]

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: sbaugh <at> catern.com
Cc: Spencer Baugh <sbaugh <at> janestreet.com>, 64088-done <at> debbugs.gnu.org
Subject: Re: bug#64088: [PATCH] Make project-root for vc projects return an
 absolute path
Date: Wed, 23 Aug 2023 03:24:02 +0300

On 19/08/2023 15:57, sbaugh <at> catern.com wrote:
>>> Meaning it will be called N times (for the number of projects) every
>>> time the list is displayed, instead of just once, when the project is
>>> saved/visited. But maybe it's fine too? How slow could that be?
>> I was sad about this but I think I've got the solution now: We just
>> maintain project--list in abbreviated form and project-list-file in
>> expanded form.

Here's something else I thought of: project--write-project-list is 
called every time a different project is returned by (project-current t) 
-- i.e. when MAYBE-PROMPT=t, and when the found dir is not at the top of 
the project history already.

So under certain conditions (slow CPU/spinning media/long project 
history) it might slow down (project-current t) calls. In my testing 
it's totally fine, though, and there are possible mitigations (limit the 
history and/or move saving to kill-hook). Just something to keep in mind.

>> I think that solves all the problems: the persistent file is independent
>> of user configuration, so if the user changes their abbreviations
>> they'll get new ones the next time the file is read (presumably the next
>> time they run Emacs).  But project--list is abbreviated, so
>> project-prompt-project-dir gets abbreviated dirs.
>>
>> It does mean that if they change their directory-abbrev-alist while
>> Emacs is running they could get duplicate entries, but that already
>> could happen before this patch, and it's not a big problem IMO.
>>
>> See patch below.
> Oops, this patch needed a few tweaks.  Especially, skipping the
> expansion and abbreviation for remote files, to avoid making unnecesary
> remote connections.

Thanks! Pushed to master, and finally closing ;-)

Previous Next

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