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

[Eli Zaretskii]

> 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.

> (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.

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.  Or something.  But just treating relative file names
as strings unrelated to the (implied) default-directory is simply
WRONG in Emacs.