Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

two suggestions #17

Open
Shahin-rmz opened this issue Jun 6, 2021 · 5 comments
Open

two suggestions #17

Shahin-rmz opened this issue Jun 6, 2021 · 5 comments

Comments

@Shahin-rmz
Copy link

Thanks for very good repo. I'm from vim world and because of so much distractions, can't handle work in Juyterlab in browser.
two suggestions though:

  1. selecting in output window.
    when we get an error, we have have to select it by mouse, which is not convenient. it would be better if we could switch window and be in 'visual mode' in output window to be able to copy text and search later.
  2. vim like syntax inside cells.
    it would be better if we could use the superpowers that vim give to us, I mean something like this
@cnrrobertson
Copy link

Looks like point number 2 was mostly taken care of by afd245e. It's pretty awesome now

@stevenwalton
Copy link

stevenwalton commented Feb 7, 2025

I'm in the same boat. Using the jupyterlab browser is just jarring but I have to use notebooks at times. As a vim user there are some unintuitive behaviors when switching to the vi mode that caused me to experience that "vim is a random text generator" issue.

An example of this might be that I would want to open a new cell by typing o (or O for new one above) but when I'm at the right context level. That is, when I'm moving around cells (j,k move my cursor up one or down one cell) I'd want o or O to open a new cell (similarly I'd expect i to do what enter does at this context level). But when I'm inside a cell (j,k move up and down lines within a cell) I'd want o and O to work as currently implemented.

It is unclear to me how to properly modify the keybindings to implement this type of behavior. Is there any reference that I can look at to get a better picture of how to do this?

There can also be some weird behaviors like it appears that dd will delete multiple lines instead of just one. I'm happy to help dogfood the vim usage and log these issues or help make the defaults a little more natural to vim users if you can get me up to speed.

@joouha
Copy link
Owner

joouha commented Feb 8, 2025

It would be possible to make the cell-navigation bindings configurable, like the cell editing mode bindings.

If you could compile a list of vim-style key bindings to use in cell navigation mode that would be really useful.

The Jupyterlab Vim project might be helpful - it has various vim style bindings listed in its readme. One option would just be to replicate these as far as possible:
https://github.com/jupyterlab-contrib/jupyterlab-vim

@stevenwalton
Copy link

Sure, is there somewhere you would like me to log? It'll need to iteratively update as both I can't just sit down and hammer it out as well as while I'm using it I'm sure I'll recognize other "weird" issues. It would be nice to be public so it can be collaborative. I can also just update comments.

Would opening up a discussion be best?

But I would say that to make things the most 'vim native' would be ensuring that we have the different 'modes'. Because that is the key framework in which vim works in. Most people are familiar with the insert mode and command mode but there are other ones (e.g. visual mode). These modes all share a lot and the commands are effectively the same as long as the context is understood. After that, vim is just about understanding movement keys and command keys.

So for a natural experience I believe it makes sense to have effectively two command modes: one at the notebook level and one at the cell level. The jupyter notebooks and you kinda have this take too, where if we start from insert mode we escape into our cell command mode and another escape takes us into notebook command mode. This is great, but it isn't clear to me how to work with this in the keybinding config.

@stevenwalton
Copy link

stevenwalton commented Feb 16, 2025

Thinking about this a bit more, would there be a way to also edit or create new commands? euporie already supports being able to run colon type commands. For example, I can run :q to quit. But interestingly :x (equivalent to :wq) appears to be a remap to :q as it asks me if I want to save before quitting. Meanwhile :w doesn't work(?). Is this something also able to be remapped?

Part of what I'm thinking here is that there are plenty of vim like commands that we'd execute from here. The :x above being probably one of the most common, but more universally, something like :help <key or relevant term> is really helpful and can help users beyond vim. But another thing I think one might want to run is like :tabnew which is identical to opening a new blank notebook. Or one often does :Ex to do file exploration and then open a file.

Speaking of the :tabnew are the keybindings limited to a modifier key + normal key? (I think this is accurate?) So we wouldn't be able to do something like gt or gT to move between tabs (equivalent to :tabnext and :tabprev, respectively), overwriting the c-pagedown and c-pageup commands.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants