Comments (33)
Just so it gets mentioned here in the relevant issue: there is now a customizable variable consult-line-point-placement
with possible values line-beginning
, match-beginning
and match-end
. The default value is match-beginning
.
from consult.
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.
from consult.
@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.
from consult.
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.
from consult.
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 consult-match
which should behave like counsel-isearch
and starts generating the candidates base on the matches etc. But this depends on me figuring out how all the dynamic candidates work and it probably also depends on the matching style as in this issue.
from consult.
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.
Isearch also goes to the beginning of the candidate if you press C-r (I find it very useful for keyboard macros), but that's probably not possible with swiper and consult-line.
For more argumentation, see abo-abo/avy#316
from consult.
@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.
from consult.
@minad I want neither. I want it to go after the match. If I have the following:
(use-pakcage something
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
from consult.
@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.
from consult.
it is technically not possible as of now.
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
Can you get the text written in the minibuffer (e.g. text that the user typed) in some way? I think it's what M-x isearch-occur does. There's no completion for it and it does that right after you run the command, so that might not be the case for consult.
I rather recommend avy
Avy has the same issue. It's just incredibly confusing to use.
from consult.
Can you get the text written in the minibuffer (e.g. text that the user typed) in some way? I think it's what M-x isearch-occur does. There's no completion for it and it does that right after you run the command, so that might not be the case for consult.
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.
from consult.
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 bar baz
at the consult-line
prompt, it will match any lines that contain the substring bar
and also contain the substring baz
, in either order. Where should the cursor be placed? After baz
? After whichever of baz
and bar
comes last in the line? It gets trickier to decide when each each substring occurs more than once in the line: do I consider the first occurrence?, the last?, of the first occurences of both words, whichever comes second?
To further complicate matters I use orderless with a very non-standard configuration. In my setup, if I use consult-line
and type the input string {baz}
, it will match lines that contain the three letters a
, b
and z
in any order, anywhere in the line. So same tricky question of where I want the cursor.
As another example, again in my personal setup, if I type !baz
at the consult-line prompt, it matches lines that do not contain the substring baz
. Where should the cursor be left in this case?
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 {baz}
or !baz
mean in my personal configuration, and thus it was no easy way to figure out where to leave the cursor.
from consult.
@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?
from consult.
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:
-
consult-line stashes the actual minibuffer input somewhere (we need to save it, since by the time `consut--goto runs the minibuffer input is gone).
-
to figure out "where the match ends", given the full line and the minibuffer input you do this: starting with the full line, chop off one character at a time and ask
completion-all-completions
if the minibuffer input still matches in the singleton collection consisting of just the truncated line. The first time the answer is no, you chopped off one character too many, and that last character chopped off is "where the match ends".
from consult.
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.
from consult.
What I understand now is that my use case is pretty basic. I'll just make my wrapper function for consult-line for now.
@ me when you figure it out please
Sorry if this sounded rude, English isn't my first language
from consult.
I implemented @oantolin's algorithm. consult-line jumps to the beginning of the match during preview and for the final jump. Please test!
from consult.
Consult-line jumps to the end of the line currently. Is this right? I did it and then ran M-x straight-pull-all.
(use-package consult-selectrum
:straight (consult-selectrum :type git :host github :repo "minad/consult" :branch "main")
:bind
("C-x b" . consult-buffer)
("M-y" . consult-yank-pop)
("C-," . consult-line))
from consult.
I mean, I use consult-line as a simple fuzzy search, no regex or anything. Is this how it should work?
https://user-images.githubusercontent.com/52463107/102770642-acf46380-43ae-11eb-8be0-01a36a98c4b8.mp4
from consult.
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.
from consult.
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?).
from consult.
Also, doesn't isearch leave you at the end of the match? I thought that's the behavior you wanted to imitate.
from consult.
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?).
Yes I use selectrum. That's sad. I still didn't write my own wrapper for consult-line, only avy.
doesn't isearch leave you at the end of the match
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.
I thought that's the behavior you wanted to imitate
AFAIK consult tries to imitate swiper.
But yeah, swiper ends at the end of the match too.
from consult.
AFAIK consult tries to imitate swiper.
But yeah, swiper ends at the end of the match too.
No, it jumps to the beginning of the match.
from consult.
@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
At 5:05, he presses RET and it goes to the end of the match. I don't know if it's the default, but I wouldn't be surpised if it were.
from consult.
By default, swiper goes to the end of the match, but you can customize it
https://github.com/abo-abo/swiper/blob/d2891aab7b816aebf21ebd01ce33933a6ac6244f/swiper.el#L130
from consult.
That makes sense, the default is to match the default for isearch.
from consult.
@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.
from consult.
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 S-RET
to exit at the end). I did this so long ago I forgot exactly what the tricky direction-switching default behavior is.]
from consult.
Since consult-line
is sort of "global", and isn't really about moving forwards or backwards through the matches, I don't think isearch actual default behavior which depends on the direction would be appropriate for consult-line
. Probably something like swiper were you can configure for the start of the match or for the end, would be more appropriate.
from consult.
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
C-s goes to the end of the match. C-r goes to the beginning of the match.
When you are searching forward, first C-r goes to the beginning of the match, second starts isearch-backwards. And vice versa
isearch actual default behavior which depends on the direction would be appropriate for consult-line
I agree, it would be pretty dumb.
from consult.
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?
Yes, this is the natural thing which comes out if you implement this.
Since consult-line is sort of "global", and isn't really about moving forwards or backwards through the matches, I don't think isearch actual default behavior which depends on the direction would be appropriate for consult-line. Probably something like swiper were you can configure for the start of the match or for the end, would be more appropriate.
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.
from consult.
I hadn't noticed the searching in steps of 16, 8, 4, 2, 1. Very nice, @minad!
from consult.
Related Issues (20)
- consult-register not working anymore
- How to add advice to achieve for org buffer like to collapse all the headings after executing 'consult-org-heading'?
- How do I use `consult-line` (with live previews) with `ivy`?
- [Q] How do I hide the line numbers in, e.g., `consult-outline`?
- [Q/Bug] consult-grep (with ripgrep or ugrep) is slower than counsel-rg
- consult preview: "PDF document is damaged" but no problem viewing it directly from pdf-tools HOT 4
- [FR] Add the ability to change the initial query in `consult-completion-in-region` HOT 1
- how to use consult-fd on a list of files? HOT 6
- additional set of buffers in consult-buffer-sources
- How to search for upercase letters with outline-regexp?
- [feature request] preselect the item that is most close to current point in consult-imenu and consult-outline HOT 3
- Where is the cached stored?
- Intragration with package Breadcrumb
- Disable consult buffer preview for remote buffers
- Support project.el external roots
- consult-rg wiki advice
- [request] allow `:lookup` in `consult--multi` sources
- Handling buffer renames while switching buffers
- Decorating consult-imenu-multi output with the origin
- Add support to display the matched heading's sub-headings also as candidates in the consult-outline's completion HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from consult.