bug#74019: [PATCH] Optionally preserve selected candidate across *Completions* update

[Stefan Monnier]

>> Indeed, it might not be related.  E.g in my setup, `*Completions*` is
>> placed in a dedicated window&frame that is simply iconified/deiconified
>> as needed, so your heuristic would fail.
> (Interesting, is the code for that published somewhere?

No, it's just in my init file.

> What's the motivation for that instead of a window?)

My minibuffer is in its own frame so I need another frame to display
the completions.

> It would be nice to store info about the completion session, but we
> don't really have any concrete concept of "a completion session" right
> now, right?

That's right.  🙁

> Also, I think we sometimes want to avoid reusing *Completions* even
> within a completion session: if we're using completion in a directory
> tree containing a file /aaa/aaa, if we select "aaa" while completing on
> "/a", then "aaa" shouldn't still be selected if we complete on "/aaa/a".

I believe we can catch most of those problems by paying attention to
changes in `completion-base-position`.

[ Tho I think those cases are less problematic, because presumably the
  "old" selection happened recently enough that the users shouldn't be
  completely surprised if it's still selected (even though they may
  consider it as a misfeature).  ]

> Do you think it would be sufficient to set a "done" buffer-local in
> minibuffer-hide-completions?  That seems to be called in all the right
> places.

Yes, I believe that should do it.

> Or maybe instead of a buffer-local, we could have
> minibuffer-hide-completions do (goto-char (point-min)) so no
> completion is selected anymore.  Then it becomes harmless to reuse
> that *Completions* buffer.

Either way works for me.


        Stefan