Written for several reasons but primarily to help facilitate the goal of @johngeorgewright tree view work.
@johngeorgewright Would you mind checking out the changes? Are you still an Atom / jumpy user? (I know a lot of people are switching over to vs code)
My next plans for jumpy are either facilitate you in this endeavor or try to get that tree view wired up myself.
I'd like you to at least get contrib mention by merging in a file or something but I'm sure a lot of your stuff would go in unchanged.
Feel free to review / clean up too.
Why the new architecture?
The key difference that should facilitate you is I have a sort of contract for "labelers" now....
So the existing "words" is just an instance of one.
We could have "tree" or "tabs" or "sql cell" (if we ever get the kind of stuff that VS Code has heh)
Now, at some point I tested the N+1 "labelers" idea...that is the union of different labeling sets...
This might have since broken / not been tested well, but I think in theory that should work fine.... this imposes an ordering as well (desired IMO).
(sorry there's more)
BTW. I'd have launched this already, except not for ONE regression, on a feature that I myself do use, the ability to use visual mode in vim-mode to highlight and jump to select a whole region.
My guess is it has something to do with a .bind() that vim-mode-plus calls and that it might conflict with some object creation javascript-state-machine uses.
The thing is existing live jumpy works with both the old (now defunct) vim-mode, and the new vim-mode-plus (the standard).
I really don't want to go live with this regression unfortunately. I've looked at it .....a lot....need more hands. I might shout out some others if you don't happen to get lucky spotting it.
Actions to recreate:
select some code via v in vim-mode-plus. (so that's v, l',l` for example to highlight 2 chars)
activate jumpy
jump down in the code somewhere (note the selection stays)
move over to the right again with l (note the selection goes away) This is not an issue with the existing jumpy :(
This is a new architecture... big rewrite :\
Written for several reasons but primarily to help facilitate the goal of @johngeorgewright tree view work.
@johngeorgewright Would you mind checking out the changes? Are you still an Atom / jumpy user? (I know a lot of people are switching over to vs code)
My next plans for jumpy are either facilitate you in this endeavor or try to get that tree view wired up myself.
I'd like you to at least get contrib mention by merging in a file or something but I'm sure a lot of your stuff would go in unchanged.
Feel free to review / clean up too.
Why the new architecture? The key difference that should facilitate you is I have a sort of contract for "labelers" now.... So the existing "words" is just an instance of one.
We could have "tree" or "tabs" or "sql cell" (if we ever get the kind of stuff that VS Code has heh)
Now, at some point I tested the N+1 "labelers" idea...that is the union of different labeling sets... This might have since broken / not been tested well, but I think in theory that should work fine.... this imposes an ordering as well (desired IMO).
(sorry there's more)
BTW. I'd have launched this already, except not for ONE regression, on a feature that I myself do use, the ability to use visual mode in vim-mode to highlight and jump to select a whole region.
My guess is it has something to do with a .bind() that vim-mode-plus calls and that it might conflict with some object creation javascript-state-machine uses.
The thing is existing live jumpy works with both the old (now defunct) vim-mode, and the new vim-mode-plus (the standard).
I really don't want to go live with this regression unfortunately. I've looked at it .....a lot....need more hands. I might shout out some others if you don't happen to get lucky spotting it.
Actions to recreate:
vin vim-mode-plus. (so that'sv,l',l` for example to highlight 2 chars)l(note the selection goes away) This is not an issue with the existing jumpy :(