search

jupyterlab-contrib / jupyterlab-vim

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

j key activate "activate previously used tab" #15

Open ghost opened 3 years ago

ghost commented 3 years ago

j key in normal mode actions is go down line

open my.py file and my.ipynb file select my.py tab with editor using vim keymap, press j at last line I got activate my.ipynb tab

But at the last line of script, pressing j key "activate previously used tab' which is bound to " ctrl + shift + ' " Weired behavior

axelfahy commented 3 years ago

I can reproduce, it is indeed a weird behavior.

ianhi commented 3 years ago

oh wacky. This is because the moveByCellOrLines https://github.com/axelfahy/jupyterlab-vim/blob/c4e43f940ef4be4c961608b6192412d2f3a33d1f/src/index.ts#L85 https://github.com/axelfahy/jupyterlab-vim/blob/c4e43f940ef4be4c961608b6192412d2f3a33d1f/src/index.ts#L127-L133 doesn't check if you're in a notebook so these notebook cell switching commands get run. This means you can also get the same behavior by using k at the top of the editor.

The fix for this is to add some sort of check to that function to only run the commands if you're in a notebook, not if in the editor.

ianhi commented 1 year ago

I believe this is fixed by #105

ianhi commented 1 year ago

wait maybe not - I think i was confused. WIll re-open until i can properly check.

firai commented 1 year ago

It seems like this only happens now in the first file editor instance if JL is loaded/reloaded with a URL pointing to a file editor-type document, and it doesn't always reproduce. It does not seem to happen after switching tabs.

I tried to track the modify calls when JL is loaded, but I don't comprehend what's happening. When the behavior exists, the following set of calls are logged when JL is loaded/reloaded:

onActiveEditorChanged()
shell.currentChanged() -> editorTracker -> modifyEditor()
onActiveCellChanged()
shell.currentChanged() -> notebookTracker -> modifyCell()
shell.currentChanged() -> editorTracker -> modifyEditor()
onActiveCellChanged()

When it doesn't happen, the following set of calls happen when JL is loaded/reloaded:

onActiveCellChanged()
shell.currentChanged() -> notebookTracker -> modifyCell()
onActiveEditorChanged()
shell.currentChanged() -> editorTracker -> modifyEditor()
onActiveCellChanged()

I'm not sure why there are so many changed signals fired at initial load, why the matching tracker flips back and forth, why the order of how it flips changes from load to load, or how the extra flip in the former case causes this behavior. Don't know why there's always an onActiveCellChanged() call when loading file editors either.

~I wonder if the shell signals should be connected to the onActive... calls to fix some sort of race condition.~ EDIT: That doesn't fix the issue.

firai commented 11 months ago

The current behavior seems to be caused by notebookTracker.activeCellChanged or editorTracker.currentChanged signals firing as background tabs are initialized, but the resulting onActiveCellChanged() -> modifyCell() or onActiveEditorChanged() -> modifyEditor() operation modifies the editor or cell in the foreground.