GNU bug report logs - #67310
[PATCH] Include the project--list as history when prompting for a project

Previous Next

Package: emacs;

Reported by: Spencer Baugh <sbaugh <at> janestreet.com>

Date: Mon, 20 Nov 2023 19:59:02 UTC

Severity: wishlist

Tags: patch

Full log


View this message in rfc822 format

From: Juri Linkov <juri <at> linkov.net>
To: sbaugh <at> catern.com
Cc: 67310 <at> debbugs.gnu.org, Dmitry Gutov <dmitry <at> gutov.dev>, eliz <at> gnu.org, Spencer Baugh <sbaugh <at> janestreet.com>
Subject: bug#67310: [PATCH] Include the project--list as history when prompting for a project
Date: Tue, 19 Dec 2023 19:35:28 +0200
>>>>>>> This change broke the order of 'C-x p p M-n M-n ...',
>>>>>> Could you remind me which behavior in 'M-n M-n' the aforementioned change
>>>>>> relates to? Is this supposed to be like input history as well, or the
>>>>>> contents of the completions table in a certain order?
>>>>> It's inappropriate to overwrite the history with the recently visited projects.
>>>>> Only user input should be added to history variables because it's actually
>>>>> the history of user input.  Therefore, the remaining way to access a list
>>>>> of recently visited projects is the future history with 'M-n M-n'.
>>>>
>>>> But... we do overwrite it now, manually constructing the value of input
>>>> history from project--list every time.
>>>>
>>>> So it seems like both "past history" and "future history" show the same
>>>> information now. If so, it might make sense to keep only one.
>>> It's usually not good to overwrite past history.  So it's better
>>> to keep only future history.
>>
>> I'm not sure the actual input history is useful here: in most cases,
>> it will be empty or almost empty. project history is different from
>> all others because we almost always detect it automatically. And also
>> because the total set of projects is relatively small, for each user.
>>
>> And "future history" is different for every command, including the
>> logic of how it's formed. Most users are also unaware of its
>> existence, so it wouldn't be a good idea to rely only on it.
>
> Yes, I think it's okay for project history to be treated as minibuffer
> history even though it's not actual input history.  It's not a huge
> deal, especially since the history didn't exist before.

To me the distinction between input history and project history is clear.
Especially since I added a lot of define-advice that update the most
recent project by any activity on a project: such as running 'vc-dir'
adds the current vc project dir to the top of the project list,
using Dired does the same, etc.  So I always have the most recently used
project on 'C-x p p M-n'.  Whereas I expect that 'C-x p p M-p' will get
the last project that was manually selected by the previous completion.




This bug report was last modified 1 year and 156 days ago.

Previous Next


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