GNU bug report logs - #63829
29.0.90; project-find-file's future history breaks with common-parent-directory

Previous Next

Full log

Message #17 received at 63829 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>, Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 63829 <at> debbugs.gnu.org
Subject: Re: bug#63829: 29.0.90; project-find-file's future history breaks
 with common-parent-directory
Date: Sat, 3 Jun 2023 15:19:55 +0300

Hi Eli,

On 02/06/2023 09:47, Eli Zaretskii wrote:
>> From: Spencer Baugh <sbaugh <at> janestreet.com>
>> Date: Thu, 01 Jun 2023 18:32:29 -0400
>>
>> 1. emacs -Q
>> 2. Open a project where project-files only returns files in a certain
>> subdirectory.  For example, a git repo /repo where the only file is
>> "dir/file.txt".
>> 3. Open dir/file.txt
>> 4. C-x p f   ;; project-find file
>> 5. Observe that the prompt is "Find file in /repo/dir: " which correctly
>> contains the common parent directory between all the paths returned by
>> project-files.
>> 6. M-n       ;; next-history-element
>> 7. The minibuffer now contains "dir/file.txt".  RET will fail to
>> open the file.
>>
>> Instead, the common parent directory should be stripped from the "future
>> history" element.
> 
>  From my POV, this is a clear sign of too many kludges which override
> the usual Emacs conventions of what is default-directory.  Stripping
> the parent directory is IMO not the right solution; instead, the
> default-directory of the command should be set so that what you want
> happens automatically.  If you go the way of patching up the code
> instead of fixing this fundamental problem, there will be no end to
> patching up.

TBH, I'm not sure which particular change you were proposing.

Do you like the patch I posted? It could be considered somewhere in that 
direction.

Should it go to emacs-29 or master?

>> (As a separate point: I ran into this while adding a feature for
>> switching between projects with similar directory structures.  I want to
>> include the relative path in the starting project in the "future
>> history", so that when you have a file in projectA open, you can switch
>> to the same file in projectB with C-x p p f M-n RET.  For example,
>> switching between the same file in multiple clones of Emacs.  But sadly
>> the future history doesn't work properly right now even in a single
>> project)
> 
> Once again, this should work by using the right value of
> default-directory; having relative filenames in the history up front
> is not TRT.  Relative file names in Emacs are always interpreted
> relatively to default-directory, so if you start using relative names
> disregarding default-directory, you will eventually run into trouble,
> as various file-related primitives will fail with ENOENT.

The problem here is that is a different/new scenario where Spencer wants 
to have a file name from one project be applied to another project. It 
seems like using absolute names would rather go in the opposite direction.

> If the default-directory can be different for some elements of
> history, perhaps each element should have the default-directory
> metadata with it, e.g., as a property.  Or maybe the history should
> hold absolute file names, and M-n etc. should convert it to relative
> as appropriate.
The latter is mostly what happens.

Previous Next

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