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

Previous Next

Package: emacs;

Reported by: Augusto Stoffel <arstoffel <at> gmail.com>

Date: Tue, 11 Oct 2022 18:30:02 UTC

Severity: normal

Tags: patch

Done: Dmitry Gutov <dgutov <at> yandex.ru>

Bug is archived. No further changes may be made.

Full log


Message #154 received at 58447 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Augusto Stoffel <arstoffel <at> gmail.com>, Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 58447 <at> debbugs.gnu.org
Subject: Re: bug#58447: [PATCH] In project-find-file, add absolute file name
 to history
Date: Thu, 15 Dec 2022 16:04:13 +0200
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..?




This bug report was last modified 2 years and 232 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.