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

[Dmitry Gutov <dmitry@gutov.dev>]

Hi Eli,

On 02/06/2023 09:47, Eli Zaretskii wrote:
>> From: Spencer Baugh <sbaugh@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.