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

[Dmitry Gutov]

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.

> > > > I just tried find-file, and the future history is empty there, so I suppose
> > > > this is something we added particularly for project-find-file.
> > > Unlike with project--list, we don't keep a list of recently visited files.
> > > Once we conducted an experiment to add all visited files to the input file 
> > > history,
> > > even when a file was visited without reading a file name in the minibuffer,
> > > e.g. by typing RET in Dired.  But no one liked this behavior.
> >
> > I don't remember that experiment,
>
> It was in https://debbugs.gnu.org/12915#121
>
> #+begin_src emacs-lisp
> (add-hook 'first-change-hook 'add-file-name-to-history)
> (add-hook 'find-file-hook 'add-file-name-to-history)
> (defun add-file-name-to-history ()
>    (when (and buffer-file-name (not buffer-read-only))
>      (add-to-history 'file-name-history buffer-file-name)))
> #+end_src
>
> but this clutters the file history too much.

That makes sense.

> > but the description sounds like recentf. Which must have its audience
> > (and I use it through Ido's "virtual buffers").
>
> 'recentf-list' looks like the right thing to add to future history
> of 'C-x C-f', but not to its past history.  This prototype works nicely:
>
> #+begin_src emacs-lisp
> (define-advice find-file (:around (ofun &rest args) recentf-list)
>    (interactive (lambda (spec)
>                   (minibuffer-with-setup-hook
>                       (lambda ()
>                         (when (featurep 'recentf)
>                           (setq-local minibuffer-default-add-function
>                                       (lambda () recentf-list))))
>                     (advice-eval-interactive-spec spec))))
>    (apply ofun args))
> #+end_src
>
> so this could be enabled by default when recentf.el is loaded.

Interesting. This way the difference between "forward history" and the 
regular one happens due to "exotic" ways to visit a file. E.g. from 
ido's "virtual buffers", or 'M-x recentf', to some older versions of 
project-find-file. I might actually be happy if they showed up in 
find-file's history too. Though if we're talking about buffers restored 
by desktop-read, for example, then no. The problem is messing with 
history's order.

Anyway, I'm mildly positive on your suggestion above, but it's probably 
a good idea to ask somebody else as well.