-
-
Notifications
You must be signed in to change notification settings - Fork 102
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
consult-line should jump to the position of the match on the line #26
Comments
I don't know a good generic way to figure out where a completion style found a match. Since completion-styles can basically do whatever they want, and are, for example, under no obligation to actually match anything, this is probably impossible to do in general. |
I had hoped for you chiming in. I have no idea how these matching styles work, so if you could describe it a bit or point me to some resources it would be good. But for now this is very low priority, maybe let's have this discussion at some other point. There is also the idea of having something like |
More than that, it also has to move to the end of the position on the line. It's the default behavior for isearch (which I use currenly for moving in my file. Nothing but isearch does that) and swiper (which I didn't use, but I watched the 10 minute example video and it goes to the end of the candidate indeed), and I believe that it's the behavior that most people would expect. I really wish I could use avy or ctrlf or consult-line, but to me they're unusable when they work like that. |
@veronikazaglotova Right now consult-line jumps to the beginning of the line. You want to have it jump to the end of the line or the end of the match? But as of now it looks unlikely we can implement the feature in a generic way, since it depends on the completion style being used and these completion-styles can do whatever they want as @oantolin said. Therefore we will probably keep the behavior of jumping to the beginning of the line. EDIT: What we could do - offer an option which allows to configure if we either want to jump to the beginning or the end of the line. But that's all we can do as of now. |
@minad I want neither. I want it to go after the match. If I have the following:
and want to fix the typo, I want to search for "use-pak", then RET. After that cursor moves to letter "c". I type C-t, and it fixes the typo. Here's how it looks like when using isearch: https://streamable.com/rsjldc |
@veronikazaglotova As I said, it is technically not possible as of now. But for such local jumps I rather recommend avy. I use consult-line differently, e.g., if I want to edit something in the context of multiple occurrences of some string, not for local jumps. |
I don't know ELisp and didn't really understand what you were talking about in this thread, if that's a dumb question just ignore it
Avy has the same issue. It's just incredibly confusing to use. |
Yes, that is possible. But the problem is that it is not clear what the text in the minibuffer means. It could be a regular expression, plain text, flex matching string, depending on the completion-style. Therefore it is hard to implement a general solution here. |
Let me give a concrete example, @veronikazaglotova, illustrating that this is not just a programming problem, you also have to decide where you want the cursor and it is a complicated question! I use a completion style called orderless that lets you match several patterns in any order. If I type To further complicate matters I use orderless with a very non-standard configuration. In my setup, if I use As another example, again in my personal setup, if I type And, of course, there is also the programming problem: even if I manage to figure out where I want the cursor, how would consult know? The consult package doesn't have an easy way of knowing what |
@oantolin The question is if we could somehow hook a function into consult which tells it how the match looks. Orderless could provide such a function and we could write similar functions for the default matching styles? |
Well, as usual selectrum throws its non-standard wrench into the mix, but ignoring selectrum, here's an idea that might work for all completion-styles:
|
Oh, that same method works for selectrum too, right? It has a function to filter the candidates, which we can use to test which truncations of the line match. |
What I understand now is that my use case is pretty basic. I'll just make my wrapper function for consult-line for now. |
I implemented @oantolin's algorithm. consult-line jumps to the beginning of the match during preview and for the final jump. Please test! |
Consult-line jumps to the end of the line currently. Is this right? I did it and then ran M-x straight-pull-all.
|
I mean, I use consult-line as a simple fuzzy search, no regex or anything. Is this how it should work? |
I cannot reproduce this. In my case it jumps to the beginning of the match. If I type git, the cursor is at the beginning of the word git. |
Doesn't Selectrum out of the box not use completion styles? Maybe that's what @veronikazaglotova is using. In that case, completion-styles is probably at its default value, which is something like basic and partial-completion. I think, in that case, the whole line should not match and point should wind up at the beginning, so I'm confused by the video where it winds up at the end. At any rate, I'm guessing this doesn't work for Selectrum users that sidestep completion-styles by sticking with the default or by using prescient. (and my information about Selectrum might be outdated again, is it still true that using Selectrum either out of the box or with prescient, keeps your completion-styles at the default value?). |
Also, doesn't isearch leave you at the end of the match? I thought that's the behavior you wanted to imitate. |
Yes I use selectrum. That's sad. I still didn't write my own wrapper for consult-line, only avy.
Yes. isearch also goes to the beginning of the match if you type C-r (or M-x isearch-backward) which I find useful for scripting, next C-r searches backwards. I wish I could have that with ctrlf. I love macros! Imma write my own macro package for Emacs.
AFAIK consult tries to imitate swiper. |
No, it jumps to the beginning of the match. |
@minad I didn't use swiper, but I saw the demo for it which is linked in the project's readme: https://www.youtube.com/watch?v=VvnJQpTFVDc |
By default, swiper goes to the end of the match, but you can customize it |
That makes sense, the default is to match the default for isearch. |
@veronikazaglotova @oantolin We could make it also customizable in consult, it is no problem. Please create a PR if you are interested in having this configurable. |
Wait, what I said is slightly wrong isn't it? The default for isearch is not to always leave the cursor at the end of the match. Isn't the default to leave the cursor at the end if you are searching forward and to leave it at the beginning if you are searching backwards? [I just checked my init.el and apparently I customize isearch to always exit at the beginning (and bind |
Since |
C-s goes to the end of the match. C-r goes to the beginning of the match.
I agree, it would be pretty dumb. |
Yes, this is the natural thing which comes out if you implement this.
For consult-line it would make sense to have two things configurable - do you want to jump to the first/last match and do you want to jump to the beginning/end of the match. One could also fix the combinations last/end, beginning/first, which are the natural combinations due to the algorithm, depending on where you start the search, beginning or end. |
Since the match is chosen via completion, "first match" sounds much more natural than "last match" to me: the first match is the one the completion system normally picks. I think having beginning/end of match configurable is probably enough. |
I hadn't noticed the searching in steps of 16, 8, 4, 2, 1. Very nice, @minad! |
@oantolin It was slow without this speedup. Another alternative I tried was to pass a list of substrings of various length to completing-read and then advance depending on the length of the resulting filtered list. But it seemed more complex without benefits. |
Just so it gets mentioned here in the relevant issue: there is now a customizable variable |
related #7
The text was updated successfully, but these errors were encountered: