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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 3 Jun 2023 15:19:55 +0300
> Cc: 63829@debbugs.gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> 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.

I was talking about the description of the problem, and what
conclusion it caused me to draw.

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

I don't know enough about the details to have opinion of any
importance.  But if the change goes in the direction I thought we
should go, then that's good.

> Should it go to emacs-29 or master?

Unless this is a bad problem, I'd prefer that the change goes to
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 some command wants to produce file names in a different directory,
then that command should do something like

   (expand-file-name (file-name-nondirectory FILENAME) NEW-DIRECTORY)

The code which produces the original FILENAME should still produce an
absolute file name (or record its directory in some other way); it
should not know/assume anything about potential uses of that file
name.

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

I very much hope so, because anything else is going in the wrong
direction.