Le Dot `.`
godbout opened this issue · 4 comments
Le Dot .
is more complicated than expected (as usual with Vim 😅️). it's not about repeat the last motion, it's about repeating the last change. that includes changes made during Insert Mode
. repeating d
moves is easier because the last motion and the last change are identical. but for c
moves, what is being typed during Insert Mode
has to be tracked, which is not easily possible as kV, contrary to Vim, doesn't own its own buffer.
so it's gonna take time to build Le Dot .
Engine. for that reason, like the usual Vim motions, things will have to be implemented gradually.
hence this issue. please let me know which motions you use Le Dot .
with, so that i can start looking into those first. motions requested will have the highest priority.
but ultimately, for motions that involve returning to Insert Mode
and typing, that's gonna take a while. a proper solution and Engine has to be built first.
One of the main use of .
I have is to rename some token manually, e.g. I will look for /foo
, then will run c2fo
to replace foo
with whatever. Then it's a matter of running n
and .
multiple times to replace all the occurrences I need.
I understand that c2fo
enters in Insert Mode which makes this complicated, as you explained in #96 (comment)
one way could be to make kV envelope everything. which means that when you'd be in Insert Mode (normal macOS), kV also takes over. and you wouldn't be able to delete for example with option delete anymore. that way i could record everything as a Vim motion, and reapply them when the . is run.
But maybe implementing this strategy you mentioned only for short bursts of insertions like with c
, but not with i
, o
, etc. could be helpful? In this case loosing stuff like option-delete is not critical and you don't need to intercept keys when using the regular insert mode.
read, and noted. Le Dot is the most hardcore stuff i'm having to deal with currently on kV, and i honestly can't give a timeline, or even confirm that this is doable 😅️ (or worth exploding the current Engines). so, i'm here, but don't expect anything soon in this area. (although kV and its siblings are in constant development, so things will move forward one way or another.)
No problem, I expected that the insert mode was troublesome. Thank you for taking it into account though! Already your dot implementation is better than Xcode's (lack of!).
No problem, I expected that the insert mode was troublesome. Thank you for taking it into account though! Already your dot implementation is better than Xcode's (lack of!).
all credit goes to kV's users—bromanko and jannis-baum for this one—that keep pushing the boundaries and give me nice puzzles to play with! (but that one about dealing with Insert Mode/macOS is a tough one.)