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

Previous Next

Full log

View this message in rfc822 format

From: sbaugh <at> catern.com
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 67310 <at> debbugs.gnu.org, Spencer Baugh <sbaugh <at> janestreet.com>, eliz <at> gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: bug#67310: [PATCH] Include the project--list as history when prompting for a project
Date: Thu, 14 Dec 2023 01:02:58 +0000 (UTC)

Dmitry Gutov <dmitry <at> gutov.dev> writes:
> On 11/12/2023 19:12, Juri Linkov wrote:
>>>>>> 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.

I worry that making M-n produce project--list and M-p produce input
history will be confusing for users.  It would be like how history and
defaults in switch-to-buffer works, which is also quite confusing.  I
personally have no intuitive grasp of when I should use history and
which I should use defaults in switch-to-buffer.

Previous Next

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