GNU bug report logs - #66993
[PATCH] project.el: avoid asking user about project-list-file lock

Previous Next

Full log

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: sbaugh <at> catern.com, 66993 <at> debbugs.gnu.org, sbaugh <at> janestreet.com
Subject: Re: bug#66993: [PATCH] project.el: avoid asking user about
 project-list-file lock
Date: Mon, 20 Nov 2023 04:05:58 +0200

On 19/11/2023 17:23, Eli Zaretskii wrote:
>> Date: Sun, 19 Nov 2023 16:31:22 +0200
>> Cc:sbaugh <at> janestreet.com,66993 <at> debbugs.gnu.org
>> From: Dmitry Gutov<dmitry <at> gutov.dev>
>>
>> On 18/11/2023 18:26, Eli Zaretskii wrote:
>>> Even if we decide to do that (and I'm not at all sure we should), how
>>> would that solve the difficulty pointed out by Dmitry?  Even if
>>> savehist is ON by default, the user could turn it OFF, right?
>> I think the working hypothesis is that they are the same feature: if
>> project--list is used for saving the previous inputs, it can be covered
>> by savehist-mode.
> Then maybe I'm missing something: savehist is AFAIU a feature that
> saves minibuffer history, not just_any_  history.

Perhaps it would be accurate to say that it saves minibuffer histories 
by default, but it can also save other history variables when 
'savehist-additional-variables' is customized.

> Are we talking
> about minibuffer history here?  I didn't think so.

Let me try to list the similarities and differences.

Similar:

- The contents of project--list come from interactions with the user. 
They're always a result of the user invoking a command. Sometimes the 
user will input the project's directory manually in the minibuffer, 
though in many/most cases that addition will be determined automatically 
by our code (and yet would still be added to the "project history" in 
project--list, because that looks like the most helpful approach for 
this list).
- The contents of project--list are, like file-name-history, used during 
completion when the user is asked to choose the project (when it 
couldn't be or wouldn't be selected automatically).

Different:

- When writing project--list to disk, we eliminate duplicate entries, 
both consecutive and distant ones. Again, seems more useful here.
- When file-name-history is used, something else is used as the 
completion table. Whereas project--list *is* the completion table. 
Whether it should be (in certain order) also used in the input history, 
is perhaps a potential future improvement.

So I don't know if project--list is a "minibuffer history", but 
depending on the POV one might decide it's close enough.

Previous Next

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