You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
I'm always frustrated with vim keymappings in more integrated environments (e.g. jupyter notebook/lab) that the navigation feels like a clunky hybrid between vim and the environment's mappings.
Describe the solution you'd like
Perhaps "Treat jupyter notebook as a single document for vim" is a better title of this proposal? For example, hitting * on a word in a cell selects that word for searching/highlighting, n then moves to subsequent occurrences of . In vim command mode in a cell 1G moves to the first line in the cell and G to the last (and nG to line n), but after :q to quit vim mode in a cell (which I think I quite like but emphasizes a notebook as a bunch of separate "code files") that behaviour doesn't apply to navigating the document as a whole and you fall back on the "close" relatives 'gg' and 'G' for first and last cell (and their more uncanny valley friends that keep seeing me hiding code cells).
I think what I'm basically proposing is that the vim keymap takes priority(?), except for maybe if you explicitly target the "jupyter notebook cell layer" (e.g. via the left gutter?) for executing jupyter key shortcuts.
Describe alternatives you've considered
I'm not aware of equivalents. I'm sure this is a harder problem than I can imagine, which is why no one else does it. The vim keymap in jupyter notebooks didn't, vscode's vim keymap doesn't do it... But we seem to keep being limited to "being in vim mode" in isolated little puddles of code cells. It would be nice to have a smoother vim experience where I can zip about my notebook faster using more vim commands.
Additional context
I'm totally up for an education on why this is such a hard problem! ;-)
Thanks for reading this and this extension is definitely something I'm going to make an effort to get used to.
The text was updated successfully, but these errors were encountered:
Good idea, actually it is also my suggestion as well,
The problem is the same, but the approach of solution are different. Please take a look at #56 .
Do you have any updates regarding this issue?
Is your feature request related to a problem? Please describe.
I'm always frustrated with vim keymappings in more integrated environments (e.g. jupyter notebook/lab) that the navigation feels like a clunky hybrid between vim and the environment's mappings.
Describe the solution you'd like
Perhaps "Treat jupyter notebook as a single document for vim" is a better title of this proposal? For example, hitting
*
on a word in a cell selects that word for searching/highlighting,n
then moves to subsequent occurrences of . In vim command mode in a cell1G
moves to the first line in the cell andG
to the last (andnG
to linen
), but after:q
to quit vim mode in a cell (which I think I quite like but emphasizes a notebook as a bunch of separate "code files") that behaviour doesn't apply to navigating the document as a whole and you fall back on the "close" relatives 'gg' and 'G' for first and last cell (and their more uncanny valley friends that keep seeing me hiding code cells).I think what I'm basically proposing is that the vim keymap takes priority(?), except for maybe if you explicitly target the "jupyter notebook cell layer" (e.g. via the left gutter?) for executing jupyter key shortcuts.
Describe alternatives you've considered
I'm not aware of equivalents. I'm sure this is a harder problem than I can imagine, which is why no one else does it. The vim keymap in jupyter notebooks didn't, vscode's vim keymap doesn't do it... But we seem to keep being limited to "being in vim mode" in isolated little puddles of code cells. It would be nice to have a smoother vim experience where I can zip about my notebook faster using more vim commands.
Additional context
I'm totally up for an education on why this is such a hard problem! ;-)
Thanks for reading this and this extension is definitely something I'm going to make an effort to get used to.
The text was updated successfully, but these errors were encountered: