search

godbout / kindaVim.docs

Ultimate Vim Mode for macOS
https://kindavim.app
639 stars 4 forks source link

New search feature: `incsearch` #120

Open jannis-baum opened 2 years ago

jannis-baum commented 2 years ago

As far as I can tell, kV's / is currently the same as command+f under the hood. There are many things I hate about the system Find functionality that are so much better in Vim. Some of my favorite features of Vim's search compared to macOS Find are:

I know this would probably be a gigantic topic and might be way beyond feasible, but it would be so cool to have! Maybe you can steal a lot of what you need for it from Wooshy? Anyways, I just wanted to add this here even if it might be a long time until you can add it or if it might never happen.

godbout commented 2 years ago

As far as I can tell, kV's / is currently the same as command+f under the hood.

YES AND NO! for the Keyboard Strategy yes. when you deal with Inputs that are not Text. if you deal with Inputs that are Text, then it's the usual text calculations/manipulations. that being said,

  • regex

currently the Accessibility Strategy / and ? don't support regex, yes. but changing one option and:

https://user-images.githubusercontent.com/121373/186147538-2fb9db36-85b8-4e65-b64f-ec9fc71844b0.mp4

so why it's not there yet? well as usual, rabbit holes. if i allow for metacharacters, then i need to make sure the regex is proper, etc. means tests blah blah. also nobody asked before, and i don't use regex myself with / and ?. so now that you've asked, i guess it's on the list.

  • live search and match highlighting (:help 'incsearch')

AFAIK you can't have several selections under macOS, in the same Text Input. that means you'd need something à la Wooshy, that draws a canvas and highlight on top of the text. that's LOTS OF WORK. that's a completely different project (i.e. Wooshy). also, AFAIK again, you wouldn't be able to do that anyways. you can highlight portions of text with Wooshy. you highlight the whole UI object. to have access to the text, position, length, etc., you need to use what kV is using. and that means no multiple text selection.

so i don't think this is possible. (but also experience told me i know nothing and i'm mostly wrong most of the time.)

  • showing results in the correct order, e.g. if I search with /, it will always show the first result downwards from where my cursor is

this should work properly with the Accessibility Strategy (see video above). with the Keyboard Strategy, yep, can't work. there's currently a difference between the Vim implementation and kV, with the count. if the count is too high, Vim will loop and still take in consideration the count. kV just skips it. if the count is too high, it'll bring you to the first match of the text. this is something i'm aware of and it's a // TODO: in my code but i keep pretending i don't see it.

  • smart case (:help 'smartcase')

that case is smart.

  • proper highlighting of matches (:help 'hlsearch') and being able to turn the highlights off when I want to instead of having it happen on its own (:help :nohlsearch)

hmm if i get this correctly this is related to the same issue as above? now that i'm thinking about it, well, Apple can do that right? they highlight exactly pieces of words when you search for them. hmm. and probably some other apps do? although probably in their own apps, not accessing the text of other apps? so would need to go through the AX, which again doesn't allow multiple selections? yeah, another rabbit hole.

I know this would probably be a gigantic topic and might be way beyond feasible, but it would be so cool to have! Maybe you can steal a lot of what you need for it from Wooshy? Anyways, I just wanted to add this here even if it might be a long time until you can add it or if it might never happen.

i guess that one is gonna stay open for a few years. that'll be your i was there flag 😂️

godbout commented 2 years ago
  • regex

so why it's not there yet? well as usual, rabbit holes.

so i'm checking this. and of course if i allow metacharacters, then they don't work anymore as normal (escaped?) characters. but in Vim they do, so i'm not sure how it does. i think what i wanna do is if search with the metacharacters don't give any result, then i check with the characters escaped. that could work, but i'm not sure how Vim does it, and it's a huge research, so i want to go this way first and maybe you check if that works ok?

godbout commented 2 years ago
  • live search and match highlighting (:help 'incsearch')
  • proper highlighting of matches (:help 'hlsearch') and being able to turn the highlights off when I want to instead of having it happen on its own (:help :nohlsearch)

i'm not sure i get exactly what are those but could this be merged/mitigated by something like the "selection" moves as you are typing the search pattern? rather than typing your whole pattern and pressing enter.

godbout commented 2 years ago

so i'm checking this. and of course if i allow metacharacters, then they don't work anymore as normal (escaped?) characters. but in Vim they do, so i'm not sure how it does. i think what i wanna do is if search with the metacharacters don't give any result, then i check with the characters escaped. that could work, but i'm not sure how Vim does it, and it's a huge research, so i want to go this way first and maybe you check if that works ok?

also by default it seems NSRegularExpression is using egrep, not grep. Vim is using grep. so there's discrepancies. what i'm afraid again is that i implement the regex for / and ? and it ends up being broken (like the Wooshy Smart Case) and i end up having to remove it because it gives a subpar experience. but not sure, not enough of an expert in that area (yet?).

godbout commented 2 years ago
  • live search and match highlighting (:help 'incsearch')

how come this is not on by default in Vim? actually the kV way was matching the default behavior of Vim, but this is way better. (although that you mean a big rewrite not just of the motions / and ? themselves but of how my characters pending thing works.)

jannis-baum commented 2 years ago

how come this is not on by default in Vim? actually the kV way was matching the default behavior of Vim, but this is way better.

No idea to be honest! Maybe just "historical" reasons or something... anyways, the Vim tutor even covers it and I'm pretty sure there are very few people that don't use it (despite knowing about it). I agree that it is way better

i'm not sure i get exactly what are those but could this be merged/mitigated by something like the "selection" moves as you are typing the search pattern? rather than typing your whole pattern and pressing enter.

This is what incsearch does, as I believe you saw as well by your comment above. incsearch deals with the highlighting of the next match while searching, i.e. before the search is cancelled (escape) or confirmed (return). Whatever is highlighted by incsearch is where your cursor will land when you press return. If you press escape, your cursor ends up where it was before you started the search.

hlsearch, however, mainly provides the highlights after having confirmed (return) a search, i.e. the highlighting of all text that matches the search query. This highlighting stays until the user runs :noh (or :nohlsearch (note the difference to disabling the option with :set nohlsearch)).

If both incsearch and hlsearch are turned on, aside from the next match already highlighted by incsearch, all the other matches are also already highlighted during the search (before confirming or cancelling).

I think it would be fair to assume most people have both incsearch as well as hlsearch turned on.

also by default it seems NSRegularExpression is using egrep, not grep. Vim is using grep. so there's discrepancies. what i'm afraid again is that i implement the regex for / and ? and it ends up being broken (like the Wooshy Smart Case) and i end up having to remove it because it gives a subpar experience. but not sure, not enough of an expert in that area (yet?).

I can't speak for everyone but personally I wouldn't mind a different regex flavor for kV compared to Vim. I'm used to having to switch my mind back and forth between different regex flavors anyways.

so i'm checking this. and of course if i allow metacharacters, then they don't work anymore as normal (escaped?) characters. but in Vim they do, so i'm not sure how it does.

This is another one of those things I've never noticed before! Without having taken a deeper look into it, I can imagine that this would become a very deep rabbit hole. I would personally prefer just having plain (working) regex over being able to search for metacharacters without escaping them (and the potential bugs and giant effort that comes with it). If you think always having to escape metacharacters is too much of a nuisance for people who don't use regex as much, how about making regex an option people have to enable if they want it?

godbout commented 2 years ago

ok so:

  1. i think incsearch is doable, but that's heavy work. that's not even related to the move itself, that's related to my Core Engine and how i gather and store pending characters. but i agree it would be much better, so this goes definitely in The List.
  2. i don't really want to try (again) hlsearch 😂️ but if i get it correctly, this is not doable. you can't highlight several stuff in the same document. at least not with the AX API, and i don't think you can in macOS' standard buffers (not like Vim that owns its own buffer, and drawings etc.)
  3. the flavor of regex well i'd prefer sticking to Vim but honestly may not be a big deal at this stage (or like i'm giving up 😂️)
  4. well if you've never noticed probably a lot of kV's users haven't either. from my short tests yesterday, it seems that the logic is as follow: if the regex pattern is correct, Vim uses it. else it escapes the metacharacters. i do not know tho what happens if the regex pattern is correct, but nothing matches. does Vim switch to escaping the metacharacters? the reason why i don't know is that i wasn't able to find a regex pattern that wouldn't match anything but where the escaped metacharacters would 😅️ maybe that actually doesn't even make sense that it could, but i wanted to leave this question for you 😅️😂️ so is this a possible case?
jannis-baum commented 2 years ago

i do not know tho what happens if the regex pattern is correct, but nothing matches. does Vim switch to escaping the metacharacters? the reason why i don't know is that i wasn't able to find a regex pattern that wouldn't match anything but where the escaped metacharacters would 😅️ maybe that actually doesn't even make sense that it could, but i wanted to leave this question for you 😅️😂️ so is this a possible case?

This was a nice little puzzle! If the pattern is valid regex but nothing matches, Vim won't fall back to escaped metacharacters, it will just match nothing like the regex should.

Proof by example: In a file with the content

x$y

search with /x$. The search is valid regex that looks for an x at the end of a line ($). This doesn't exist in the file, hence there are no matches. The file does however contain a literal x$, which isn't matched with the search query.

So it looks like Vim will to a literal search for invalid regex as you observed, and a regex search for valid regex independent of whether there are any matches!

godbout commented 2 years ago

fantastic. i knew i was right to believe in you 😎️ gonna make things easier. i think i can implement this soon.

one thing tho, do you mind splitting the features again into several issues? from our discussion i think we can have three tings done: 1) regex support 2) incsearch 3) smart case.

i avoid opening the issues myself coz else they got into lower priority 😅️ thanks!

godbout commented 2 years ago

just some thoughts on the incsearch (for myself):

  1. that requires changing/adding lots of stuff on the kVEngine. currently we track key inputs. in the case of the / or ?, we wait for a return before firing the move. the change would require to fire the move after every keystroke that comes after /?.
  2. then we need to keep track of the caret position before the search, in case it's cancelled
  3. each time the move is fired, the search needs to start from the saved caret position, not the current position/selection that shows the result of the incsearch

basically we need a little mini search engine, within the kVEngine, that handles keystrokes differently, and that keeps track of several things.

godbout commented 2 years ago

(i will thank myself later.)