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

[Dmitry Gutov <dmitry@gutov.dev>]

On 25/11/2023 10:42, Eli Zaretskii wrote:
>> Date: Sat, 25 Nov 2023 03:54:13 +0200
>> Cc: 67310@debbugs.gnu.org, juri@linkov.net
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>> I'll try to answer some of the questions that are still relevant to the
>> latest patch, myself.
>>
>> On 23/11/2023 08:38, Eli Zaretskii wrote:
>>
>>>> +            ;; Iterate in reverse order so project--name-history is in
>>>> +            ;; the correct order.
>>>
>>> What is the "correct" order?
>>
>> Their order in project--list.
>>
>> Iteration and construction of a new list with 'push' leads to the
>> reverse order, hence the use of reversion at the beginning to counteract
>> that.
> 
> Then the comment should say
> 
>    Iterate in reverse order so project--name-history is in the same
>    order as project--list.

Sure.

>>>> -              (if-let (proj (project--find-in-directory dir))
>>>> -                  (push (cons (project-name proj) proj) ret)))
>>>> +              (when-let (proj (project--find-in-directory dir))
>>>> +                (let ((name (project-name proj)))
>>>> +                  (push name project--name-history)
>>>> +                  (push (cons name proj) ret))))
>>>
>>> Not sure I understand why you replaced if-let with when-let here.
>>
>> To reduce the amount of indentation, perhaps.
> 
> Why is that an advantage?
> 
> I generally request and expect people not to make unnecessary changes,
> since doing that makes forensics harder: you see changes which don't
> change the code's semantics, and need to waste time studying such
> "changes" and deciding that they are no-ops.
> 
> Please everyone keep this in mind when you make changes.

In general we don't frown in making minor cosmetic changes in the same 
area as major meaningful changes are done.

Conversely, we do frown on cosmetic changes when nothing else is added. 
Ergo, the only time to make such minor changes is when more meaningful 
changes are done.

If the latter was not the case, we could instead prefer the more common 
tactic of separating functional and cosmetic changes.

>>>> +        (let ((history-delete-duplicates t)
>>>> +              (history-length t))
>>>> +          (add-to-history 'project--list root))
>>>
>>> Why are you overriding the values of these two user options?
>>
>> To implement the current behavior (how additions to project--list)
>> happen. I've described that behavior in one of the earlier messages here.
> 
> I think this is not a good idea, regardless of the reasons.  Users
> have these options to control how history functionality behaves in
> Emacs, and here you take away that control with no "fire escape".

Actually, never mind: the latest version of the patch doesn't use 
'add-to-history', or reference these variables.