Save input in history on C-g

[mrcnski]

Hi! I have this common workflow:

1. I do consult-ripgrep to search something up, see what I needed to in the preview, and then C-g.
2. Later I want to search for the same thing again, so I consult-ripgrep and press M-p to cycle back through input history,
3. but the last input was not saved because I had quit with C-g.

So yeah, I hope that made sense and I wonder if it's possible? Thanks!

[minad]

Hi,

unfortunately this is not possible directly with Consult. This also bothers me quite a bit, in both the case of C-g and the case of embark-export. The problem is that we cannot easily distinguish if C-g was pressed to abort (and the input should indeed be dismissed) or if C-g was only pressed to close as you described.

One solution is offered by the Vertico extension vertico-repeat, see the Vertico repository. There the input is always preserved even for C-g and embark-export. You can restart Vertico and select the input via vertico-repeat-select. The difference is that the repeat history is separate from the normal minibuffer history, so it may not fit perfectly for your workflow. Does this help?

[minad]

I've decided to change the behavior, see 4309a19, since we already differ from the default by saving the input. I think it is better like this, since search is often started, used for preview and then aborted either via C-g or embark-export. Please let me know if it works as expected.

[mrcnski]

Woah. Thanks so much for the quality of life improvement! You're awesome!

In my testing I only noticed one minor thing: M-x still has the old behavior, and I couldn't find a consult-M-x command. (I thought I remembered there being one, maybe not.) Or is this one of those commands that doesn't opt-in to the input history? Not a big deal. :)

[minad]

In my testing I only noticed one minor thing: M-x still has the old behavior, and I couldn't find a consult-M-x command. (I thought I remembered there being one, maybe not.) Or is this one of those commands that doesn't opt-in to the input history? Not a big deal. :)

Yes, M-x is not a Consult command and does not store the input. M-x stores the selected command in the history, and this only works when completion has successfully finished (and was not C-g aborted). It is a big deal to keep it like this, since changing it would for example break sorting the commands by recency. Note how recently invoked commands appear earlier in the list. I am convinced you would not want me to break this. ;)

The aforementioned change only affects somewhat special Consult commands which use the minibuffer history in a different way than usual and store the input. Most commands are not affected, none of the built-in commands is affected. You can grep the Consult source for :history and :input to see the affected Consult commands.

I should add, for built-in commands you can still recover the input via vertico-repeat, which I had mentioned before. I think this is an acceptable design overall, since you can still recover complex filter input. Storing both the candidate and input history is something which has bothered me for a long time. While working on Selectrum I created the now obsolete Uchronia, which then turned into vertico-repeat.

[mrcnski]

Ah makes sense. I see consult-buffer is not affected, but I kind of wish it was, since I often have multiple files named a similar way (i.e. mod.rs in Rust projects). And it would be more consistent, but it would break sorting recent buffers... Maybe an opt-in is possible? Anyway, this satisfied 99% of my usecases, feel free to close the discussion!

[minad]

See above - I suggest to use vertico-repeat in the cases where one wants both the candidate history and the input history. You can use this for M-x, consult-buffer and so on. Storing the input history and only the input history makes sense only for very few commands, namely the commands of the consult-line and consult-grep class.

The use case with the similarly named buffers should be solved in a different way, with a different workflow imo. Maybe use a different buffer naming scheme (the uniquify functionality) or maybe separate projects via workspaces...

[minad]

I think we can do better than what we have right now and even solve your use cases 100%. :)

Currently we have vertico-repeat-last and vertico-repeat-select. For example from consult-buffer invoke one of these vertico-repeat-* commands. This way you can restore the input for every command.

What is missing are two special commands vertico-repeat-next and vertico-repeat-previous. These could be bound to M-N or M-P (or even M-n or M-p) and would allow to step through the input history. The normal commands previous-history-element and next-history-element would still allow you to step through the candidate history.

[minad]

Implemented here: minad/vertico@43c0902

[mrcnski]

I appreciate this so much.

Initially I was getting an error: vertico-repeat--run: No repeatable session. Eventually I realized that I had missed the minibuffer-setup-hook config. 🤦‍♂️

Also, do the commands in the docs at https://github.com/minad/vertico/blob/main/extensions/vertico-repeat.el#L30 need to be updated?

Thanks again!

[minad]

You're welcome.

Also, do the commands in the docs at https://github.com/minad/vertico/blob/main/extensions/vertico-repeat.el#L30 need to be updated?

No, the docs seem alright. We have vertico-repeat, vertico-repeat-select, vertico-repeat-previous and vertico-repeat-next.

[mrcnski]

Thanks. This was one of my best experiences with open source. BTW, I just (coincidentally) found out that "quitting" and "aborting" are indeed two different concepts: https://www.gnu.org/software/emacs/manual/html_node/emacs/Quitting.html

[minad]

On 11/29/23 09:49, Marcin S. wrote: Thanks. This was one of my best experiences with open source. BTW, I just (coincidentally) found out that "quitting" and "aborting" are indeed two different concepts: https://www.gnu.org/software/emacs/manual/html_node/emacs/Quitting.html <https://www.gnu.org/software/emacs/manual/html_node/emacs/Quitting.html>

Thanks! Yes, quitting and aborting are different with respect to recursive minibuffers. However in our context here, it does not make a difference. If the completion command is aborted/quitted, no candidate is selected, no candidate is stored in the history, and the code in the continuation of completing-read is not executed. Usually the selected candidate is stored in the minibuffer history after the minibuffer closed in a regular way. We are working this around here only for input histories with unwind-protect.