[Feature request]: Select last selection (still highlighted in buffer) instead of giving Match required error

[prosoitos]

I would love it if there was a way to validate the last selection, as seen in the buffer, when there is no more valid match in the minibuffer.

Indeed, it happens to me all the time (because I type fast and often make typos) that the place where I would like to go with some consult function or other is selected in the buffer, yet, because of an unfortunate bad last character, the selection is not available in the minibuffer anymore.

This picture shows what I experience countless times every day. In this situation, I wish that pressing Enter would take me to that Copilot line that is highlighted in the buffer. That would seem so natural considering that the line already looks like it's been selected. Instead I get that Match required error and have to edit my prompt.

I know that I could use flex in orderless, but I don't want to because then I would have everything and anything show up as a match. I really love the behaviour I have in my current settings of vertico, consult, and orderless, except from this situation I keep getting into.

Might it be possible to have vertico take me to that place that I can already see, right there, in the buffer instead of giving me a Match required message?

@oantolin in #10 seems to suggest that he doesn't think that a match should be required. This is clearly how I feel: as I navigate a buffer with consult-line, consult-outline, etc., my eyes are on the buffer, not on the minibuffer. So by the time I get to the picture above, in my head, I have already gotten the match I wanted and it is always a surprise to get an error instead of just landing where I thought that I already was.

Thank you so much and thank you so very much for such wonderful packages! ❤️

[oantolin]

Well, it's true that generally speaking I dislike requiring a match, and I even have the following in my configuration:

(defalias 'vertico-really-exit-input 'exit-minibuffer)
(keymap-set vertico-map "C-<return>" #'vertico-really-exit-input)

(Note that I don't override the binding for vertico-exit-input because I do also like the safety it brings... 🙄)

But that sort of thing doesn't help in your case since consult commands only know how to jump to their candidates, not to some random non-matching string. I'm actually not sure how I would implement this behavior. Maybe @minad will have a suggestion.

[prosoitos]

Well, it is not exactly some random non-matching string: it is the location currently highlighted in the buffer (although, I have no idea how it works under the hood).

[prosoitos]

In the situation shown in the picture (which is perfectly typical), typing cop selected a match and highlighted the location in the buffer.

Adding the extra y—which makes my string not match anything anymore—does not cause the highlighting in the buffer to disappear (the line is still highlighted, the letters cop are still highlighted as a match).

Which is what makes the behaviour so annoying to me. Because, looking at the buffer, it looks as if there was still a match (even though, indeed, there isn't anymore).

Maybe whatever is maintained and which causes the last match to keep its highlighting can be used?

[minad]

The behavior you are wondering about here is caused by two different packages. Vertico is responsible for computing the matches and Consult highlights the currently selected candidate. In this case Consult remains at the position of the last match in order to avoid bouncing around aggressively. If you use Isearch, the behavior is exactly the same. Type something and then enter more non-matching characters. You will stay the position of the last match and the last match will stay highlighted.

[prosoitos]

Ah. Right. I see. That makes sense.

[minad]

(I moved the discussion from Vertico to the Consult repository, since it fits there much better.)

I think we could remember the last matches and show that (maybe on the level of the completion style). But I honestly think it is not a good idea to do this. Other completion commands or Isearch also doesn't find matches if your input does not match. You could try to use a more forgiving completion style (flex or typo).

Regarding the "match required" message - the message is there for a reason. It means that the command cannot handle the given minibuffer input. If the completion session would exit the value you would just get an error as a result, which is worse than a "match required" message, where you still have a chance to correct the mistake. For example if you exit M-x with a non-command it will just error.

However there are cases, where commands are too restricted. They could in principle handle more minibuffer inputs, but they opt not to do that. In those cases I agree that the "match required" message is harmful and I guess that these are the cases, where Omar prefers plain exit-minibuffer. Ideally the commands would be relaxed to handle more inputs, such that we still get "match required" error checking where necessary, but only there.

[prosoitos]

I tried flex, but I don't like it because it is hard to narrow on the location where I am trying to get to. There are just too many matches.

Oh well. I guess I will just have to stop making so many typos 😆

[minad]

Oh well. I guess I will just have to stop making so many typos 😆

I actually wanted to suggest that, but then I forget. Yes, I think you should do that. Emacs will help you with that 😆

[oantolin]

I should say that nowadays there is really only one common task where I want to avoid the match required behavior and it's my own fault 😬: when choosing a non-command function as action for embark at the M-x prompt. Still, having vertico-really-exit-input is good for that case alone.

[oantolin]

And to your point, @minad, I could change embark's M-x to prompt for functions rather than commands, but I think that the vast majority of the time that would be too much noise in the candidate list. It's probably better to prompt only for commands and let weirdos like me who sometimes want non-interactive functions add a keybinding for exit-minibuffer.

[oantolin]

I have a vague recollection of needing exit-minibuffer in another common case in the past, but either that code has changed or my habits have and it doesn't seem to come up anymore, to the extent that I cannot remember what it was.

[oantolin]

As a simple workaround you can use other-window to go to the window showing the last match and then abort-recursive-edit to close the minibuffer, so C-x o C-]. Maybe you could even use:

(defun exit-keeping-point ()
  (interactive)
  (select-window (minibuffer-selected-window))
  (abort-recursive-edit))

(keymap-set vertico-map "C-<return>" #'exit-keeping-point)

That's the same idea, but I think the minibuffer-selected-window expresses intent better than relying on other-window taking you to the right place.

[prosoitos]

Oh, I like this suggestion 🙂 Thank you!

[prosoitos]

Works like a charm.

I guess I could even bind it to <return> and then I would really have my wanted behaviour.

But maybe that is a bit crazy.

Although... it is tempting. Maybe I'll do that for a bit and see whether that leads to bad things in some circumstances.

[prosoitos]

I am a bit unclear still about when vertico and/or consult commands push positions into the mark ring. For the most part, they do (which is great), although sometimes I seem to not have my last position in the mark ring after jumping around with one or another command.

Maybe binding your function to <return> would affect adding positions to the mark ring. I guess I could have a look at the source code or just try it and see what happens.

[prosoitos]

Oh, never mind. It only works to jump within a buffer, not between buffers. So I definitely need to keep it to a different key.

But I will use this function. Thank you!

Edit: I played with it for a bit and it is really great and a lot smoother than editing my typo 🙂

[minad]

Bad news, see #924 (reply in thread) :(

EDIT: We can still create a similar command as @oantolin's, which first records the current location and then restores it after minibuffer exit.

[prosoitos]

Does this mean that I should close this discussion?

If it were an issue, I would, but I am not sure what the best practice is for discussions.

It seems that my suggestion was rejected as a default behaviour, but I got offered a nice workaround. So maybe this is it on the topic???

[oantolin]

The command suggested by Omar in #924 (comment) only worked because of a bug,

You mean "now-removed feature" instead of "bug". 😛

[prosoitos]

Ah ah ah ah ah

Bummer. I guess I'll have to try to create a new function indeed as it was quite nice

[minad]

@oantolin it was really a bug, even in contradiction to the docstring of consult--with-preview. But of course, it is fun to lock down the the mini buffer even more, trapping the users and catching them with the evil modal claws 😈

[oantolin]

So, is this new version correct?

(defun exit-keeping-point ()
  (interactive)
  (let ((location (with-minibuffer-selected-window (point-marker))))
    (run-at-time 0 nil #'consult--jump location)
    (exit-minibuffer)))

[minad]

The new command works well. Given this command I think we can keep the existing behavior for now. @prosoitos Note that you can bind the command only for consult-line or consult-outline like this:

(consult-customize
  consult-line consult-outline
  :keymap (define-keymap "RET" #'exit-keeping-point))