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 #136 received at 58447 <at> debbugs.gnu.org (full text, mbox):

From: Augusto Stoffel <arstoffel <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 58447 <at> debbugs.gnu.org,
 Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#58447: [PATCH] In project-find-file, add absolute file name
 to history
Date: Wed, 14 Dec 2022 20:32:46 +0100
On Wed, 14 Dec 2022 at 20:45, Dmitry Gutov wrote:

> On 14/12/2022 18:47, Augusto Stoffel wrote:
>> On the other hand, your trick works by accident.  If you switch between
>> unrelated projects, then 'C-x p f M-p' brings up a non-existing file.
>> One might say each project should have its own history, but then it's
>> not clear whether/when equally named projects in different locations
>> should count as "the same" project.
>
> Perhaps the first step to resolving all this is for project-find-file
> to use a different history variable than find-file.

This is fine by me, but do you feel confident such a variable will be
a good design for the long run?  In particular, have you discarded the
idea of per-project history variables?

The advantage of my suggestion (filter the file-name-history on the fly)
is that no new variables need to be defined, so nothing needs to be
obsoleted and phased out if we change our minds.

> Which makes sense, given that one (usually) uses relative file names,
> and the other -- absolute ones.
>
> Maybe project--read-file-absolute could continue using the current
> variable, too.
>
> As a result, all projects will share history, for good and
> bad. Perhaps next we could do something about that, e.g. if the
> history iteration could allow pre-filtering, we could also filter out
> non-existing files.

This kind of filtering would be slower than the one I proposed, and
prohibitively slow over Tramp, I think.




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.