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

[Dmitry Gutov <dgutov@yandex.ru>]

On 15/12/2022 13:07, Augusto Stoffel wrote:
> On Thu, 15 Dec 2022 at 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?
> 
> I don't think this should be the default behavior at all.  To me it
> seems much more likely that a user _does not_ want to see files from
> other projects when doing `C-x p f M-p'.

Do you think they will mind too much? At least if the relative names are 
shown, the user will recognize them and won't be too surprised.

> Your workflow seems more of a job the "find related file" feature that
> has been discussed recently in the list.
> 
>> 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.
> 
> Then let's do the opposite.  We define 'project-file-history-variable'
> and let it be nil by default.  In this case, we get the behavior of
> Dmitry's patch v2.  If it's not nil, then we assume it's to be used
> as-is, with no filtering or removal of project root prefix.  The user
> can set it whatever way they please and take care it makes sense.

The problem with that is storing relative history in such a variable 
will only work with one of the values of 
project-read-file-name-function. So we'll have two defcustoms which need 
to be changed in concert..?