jupyterlab-contrib / jupyterlab-vim

Vim notebook cell bindings for JupyterLab
https://jupyterlab-contrib.github.io/jupyterlab-vim.html
MIT License
661 stars 43 forks source link

Navigating above the first cell in vim mode loses focus, if the first cell is a Markdown cell #52

Closed gtmaskall closed 8 months ago

gtmaskall commented 2 years ago

Description

Navigating up through cells using 'k', you scroll through code cells line by line and as you pass through markdown cells they're displayed as markdown and then rendered again upon exit. Continuing upwards "above" the first cell loses keyboard focus for the notebook, forcing you to click back on the notebook area with the mouse.

Reproduce

  1. Position cursor near top of notebook
  2. Make sure you're in vim mode (hitting 'enter' if need be)
  3. Scroll up using 'k'
  4. Hit 'k' again after reaching the first cell. Any further keyboard navigation is lost.

Expected behavior

The 'j' key should continue to work as before, so although 'k' has nowhere further to go, you're at "the top" of the file and 'j' should still work to go back down.

Context

I don't think anything else is relevant. It's a fresh install from anaconda to jupyterlab_vim version 0.14.5 with Python 3.8.11.

But I would like to add that I think this extension will allow me to migrate from jupyter notebook to jupyter lab. The keymap summary in the GitHub README is super helpful - thank you. Of course there are new keymaps to use, and half the point of using a vim keymapping is to use 30 years of muscle memory(!) but the basic navigation seems to make sense and it's definitely something I'll be trying to get familiar with. There are definitely behaviours of it that I'm liking, and that I struggled to find how to do using the jupyter notebook vim keymap. (I find the ctrl-[1, 2, 3] a little unintuitive, but easy enough to toggle through by trial and error).

ianhi commented 2 years ago

I wonder if this is actually an issue in jupyterlab (or perhaps intended behavior). We rely on the Notebook function selectAbove to do this https://github.com/jupyterlab-contrib/jupyterlab-vim/blob/3f1315b6b864ab7a887055bce09f07187ab4a3f3/src/index.ts#L386

So unless there is some other API for this that may require an upstream change. I see also that this is different than the arrow key behavior so this is definitely a bug.


Of course there are new keymaps to use, and half the point of using a vim keymapping is to use 30 years of muscle memory(!) but the basic navigation seems to make sense and it's definitely something I'll be trying to get familiar with. There are definitely behaviours of it that I'm liking, and that I struggled to find how to do using the jupyter notebook vim keymap.

There is currently no remapping of the jupyter vim bindings (although there really ought to be) but for the vim editing bindings you may also want to check out https://github.com/ianhi/jupyterlab-vimrc#jupyterlab-vimrc so you can add some of the keybinds from the past 30 years :)

(I find the ctrl-[1, 2, 3] a little unintuitive, but easy enough to toggle through by trial and error).

I've also found this to be unintuitive but at this point it's probably not something we should change as so many people have learned these. But it definitely should be configurable (see above comment)

ianhi commented 2 years ago

Interestingly the jupyterlab api seems to be a no-op if the first cell is selected, so I'm not sure why it is in fact doing things :thinking:

https://github.com/jupyterlab/jupyterlab/blob/8dad476d9285e751607d0b4f59a3d5b18071dcc2/packages/notebook/src/actions.tsx#L769-L775

ianhi commented 2 years ago

oh actually I think I see why. It's because these are conflicting goals:

   * This is a no-op if the first cell is the active cell.
....
   * The existing selection will be cleared.
firai commented 9 months ago

I don't have edit privileges, but I believe this should be named "Attempting to navigate above the first Markdown cell in vim mode loses focus".

This seems to be caused by rendering of the Markdown cell when the user attempts to navigate away from the cell and the fact that this plugin can currently only navigate inputs. The action therefore causes the active input to be de-focused, while the selection has nowhere to go.

krassowski commented 9 months ago

@firai you should be able to rename issues now, let me know if this is not the case.

kllmanu commented 9 months ago

I've the same issue, very annoying, once you lose focus you've to select a cell by mouse manually. One work around so far is the shortcut to selec the first or last cell to get the focus back at least.