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

[Eli Zaretskii]

> 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.

> >> -              (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.

> >> +        (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".

As for the description you allude to above, all I found is this, which
is part of Spencer's commit log:

  The project--list is already ordered such that the most recently used
  projects are at the front.  Now we use it as the minibuffer history
  when prompting for a project.

  To avoid savehist from picking up project--list as a minibuffer
  history variable and overriding our own persistence mechanism, we
  don't pass project--list directly as a history variable, but instead
  pass project--dir-history or project--name-history, dynamically-bound
  to an appropriate value.  project--dir-history and
  project--name-history won't be persisted since they're always unbound
  at the top level; but if they are persisted anyway somehow, it won't
  affect us.

  If we later find a way to rely on savehist for persistence instead of
  having our own mechanism, we can change the in-memory format of
  project--list to be just a list of directories, and our explicit calls
  to project--add-dir can be replaced by let-binding
  history-delete-duplicates=t, history-length=t.

If this is what you mean, then I don't see how this justifies the
overriding.