bug#58447: [PATCH] In project-find-file, add absolute file name to history

[Dmitry Gutov]

On 15/12/2022 09:24, Juri Linkov wrote:
> > The patches could be combined, but v1 seems to be too invasive for
> > emacs-29, yet v2 could be just small enough to be considered "bugfix-only".
> >
> > So, what does everyone think about the latter?
> >
> > If people agree that the v2 patch is an improvement, we can check it in and
> > leave project-local histories until later.
>
> Does the second patch allow such workflows as re-visiting
> the same relative filenames in another directory?

Not really; it filters by project root (more or less).

As long as we have global history, it's hard to extract the relative 
names for it, if they belong to a different directory tree.

But the history storage seems to retain text properties. So I suppose 
one option would be to annotate the "relative" part with a text 
property, before adding the string to history. And then look up the text 
property later.

> IMHO, the safest fix for emacs-29 would be to add relative filenames
> to the separate history.  If someone might want to use
> 'file-name-history', then a new variable could be added like
> 'query-replace-from-history-variable'.  Then this variable
> could be customized to 'file-name-history', or nil.
>
> It's needed only when 'project-read-file-name-function'
> is 'project--read-file-cpd-relative'.

It can work, but having a user option that only works for 
project--read-file-cpd-relative is pretty awkward. Beginning with having 
to choose its name.

If we do this, I'd rather that happens on master, and we choose 
something smaller for emacs-29.

And the text property trick above could both "store" the relative 
history and also keep adding entries to 'C-x C-f'.

> But please also note that its value 'project--read-file-absolute'
> is also broken.  It asks confirmation for re-visiting even absolute
> filenames, because currently 'C-x p f' adds abbreviated filenames,
> but confirmation checks for absolute.

Does the breakage show itself only when you add a history entry using 
one value of project-read-file-name-function and then try to look it up 
when using another value of project-read-file-name-function?

If so, that's probably bearable enough for now (people don't really 
change this value often). Fixing it will require resolving the 
abbreviation situation. And we might as well switch to relative names in 
project-files first.