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

Previous Next

Full log

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Augusto Stoffel <arstoffel <at> gmail.com>
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, 27 Oct 2022 19:07:35 +0300

On 27.10.2022 18:56, Augusto Stoffel wrote:
> On Thu, 27 Oct 2022 at 18:36, Dmitry Gutov wrote:
> 
>> On 27.10.2022 17:26, Augusto Stoffel wrote:
>>> One thing to consider here is compatibility with savehist-mode and the
>>> like.  I guess the only simple way to achieve this is with one global
>>> variable per project.
>> I suppose interning a symbol with the project root directory in its
>> name could work.
> The project root directory or the project name?  I'd say the latter.

We don't have a "project name" generic yet. There is a bug open.

And even so, unrelated projects could declare equal names, couldn't they?

> If you have two copies of the same project in two different places
> (which I often have -- a local copy and one in a remote compute
> machine), then the shell and compilation buffers are shared.  One can
> argue whether this is good or bad (I find it okay, with some caveats),
> but for the sake of consistency the history variable should also be
> shared among copies of the same project.

I imagined the project names would be used in the project selector 
instead of their root directories, not in addition to them. So they'd 
have to be unique even across "copied projects".

But you can bring up that idea in bug#48747.

>> Passing it to completing-read will unavoidably result in relative
>> names still, though. But it won't be so much of a problem anymore.
> If we settle for one history variable per project, then I'd say yes, the
> entries should be relative file names.

Ok.

>>> And then there would be the issue of when to
>>> garbage-collect the saved save pertaining to old projects.
>> Inside project--remove-from-project-list? Either one specific project,
>> or doing a full scan of obarray.
> Okay, if "garbage collection" of projects is already a thing, then we
> just have to extend it to contemplate the history variable.

There is no "garbage collection" point exactly, but we could pivot to 
making one.

The main reason I didn't do that is scanning the full project list with 
file-readable-p check will likely become slow quickly enough, especially 
in the presence of remote projects.

Previous Next

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