Closed kiyoon closed 5 months ago
@sahinakkaya Thanks for testing! Would it be possible to keep it in your config and try it for some time? Because the last thing we want to do is to ask all users to change their config only to see another issue that we have to roll back.
Yeah, sure. I was already planning to keep it until this is merged.
Also just tested it and can confirm it works :)
@ribru17 I've also been using this and had no problem so far. Do you think it's ready to merge?
If it applies cleanly to the main
branch.
@clason Yes it does, it's separated from the module structure.
I can make a separate PR for the main branch if it's needed. I don't know if it can be just rebased as main branch has a little bit of refactoring.
Rebasing would be preferred (also to keep main
up-to-date with respect to query changes). This will require some manual conflict resolution, but hopefully nothing too involved.
I can rebase and make the PR.
No, no need to make a PR -- just git checkout main; git rebase master
, resolve any conflicts, then git rebase --continue
. Lather, rinse, repeat, and then just git push -f
.
fixes #519
The current implementation of builtin
f
,F
,t
,T
is a re-implementation to match the behaviour of the nvim upstream. Although it works with;
and,
movement repeat, unfortunately it probably wouldn't work with complex combinations (e.g.dfe
and.
repeat wouldn't work).Instead, we can make
builtin_f_expr
,builtin_F_expr
, ... just returns"f"
,"F"
,"t"
,"T"
character so you can use it to map with{expr = true}
. See the implementation below. This will almost likely resemble the upstream behaviour in most of the situations.Before returning the string, note that it also maps the last movement so the
;
and,
mapping can handle it as well.Important: users must change their keybindings to include
{ expr = true }
. I updated the README.md as follows:The original functions
builtin_f
etc. are left unchanged, except it will notify the deprecation warning once.