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

[Dmitry Gutov]

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.