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

Escape goes directly from vim input mode to jupyter command mode #31

Closed marvinbernhardt closed 2 years ago

marvinbernhardt commented 3 years ago

Solution :tada:

Versions 0.15.0 and up do not have this issue. pip install --upgrade jupyterlab-vim

Workaround:

A persistent workaround to this issue is to add the following to the Shortcuts settings (Settings > Advanced Settings Editor > Keyboard Shortcuts)

{ "shortcuts": [
    { 
        "command": "notebook:enter-command-mode",
        "keys": [ "Shift Escape" ],
        "selector": ".jp-Notebook.jp-mod-editMode" 
    },
    {         "command":"notebook:enter-command-mode",
         "keys":[
            "Escape"
         ],
         "selector":".jp-Notebook.jp-mod-editMode",
         "disabled":true
    }]
}

as discovered from https://zhuanlan.zhihu.com/p/105642669 by @gofortargets.


And when I go back in the cell I go directly back to vim input mode. I have to focus another cell, to get vim command mode back.

Peek 2021-03-22 16-23

Is it a problem, that I use two envs, one for jupyter-lab and one for the kernel?

The conda env for jupyter-lab ``` name: jupyter channels: - conda-forge - defaults dependencies: - _libgcc_mutex=0.1=conda_forge - _openmp_mutex=4.5=1_gnu - anyio=2.2.0=py39hf3d152e_0 - argon2-cffi=20.1.0=py39h3811e60_2 - async_generator=1.10=py_0 - attrs=20.3.0=pyhd3deb0d_0 - babel=2.9.0=pyhd3deb0d_0 - backcall=0.2.0=pyh9f0ad1d_0 - backports=1.0=py_2 - backports.functools_lru_cache=1.6.1=py_0 - bleach=3.3.0=pyh44b312d_0 - brotlipy=0.7.0=py39h3811e60_1001 - ca-certificates=2020.12.5=ha878542_0 - certifi=2020.12.5=py39hf3d152e_1 - cffi=1.14.5=py39he32792d_0 - chardet=4.0.0=py39hf3d152e_1 - cryptography=3.4.6=py39hbca0aa6_0 - cycler=0.10.0=py_2 - decorator=4.4.2=py_0 - defusedxml=0.7.1=pyhd8ed1ab_0 - entrypoints=0.3=pyhd8ed1ab_1003 - freetype=2.10.4=h0708190_1 - idna=2.10=pyh9f0ad1d_0 - importlib-metadata=3.7.3=py39hf3d152e_0 - ipykernel=5.5.0=py39hef51801_1 - ipympl=0.6.3=pyhd8ed1ab_0 - ipython=7.21.0=py39hef51801_0 - ipython_genutils=0.2.0=py_1 - ipywidgets=7.6.3=pyhd3deb0d_0 - jedi=0.18.0=py39hf3d152e_2 - jinja2=2.11.3=pyh44b312d_0 - jpeg=9d=h36c2ea0_0 - json5=0.9.5=pyh9f0ad1d_0 - jsonschema=3.2.0=pyhd8ed1ab_3 - jupyter-packaging=0.7.12=pyhd8ed1ab_0 - jupyter_client=6.1.12=pyhd8ed1ab_0 - jupyter_core=4.7.1=py39hf3d152e_0 - jupyter_server=1.4.1=py39hf3d152e_0 - jupyterlab=3.0.12=pyhd8ed1ab_0 - jupyterlab_pygments=0.1.2=pyh9f0ad1d_0 - jupyterlab_server=2.3.0=pyhd8ed1ab_0 - jupyterlab_widgets=1.0.0=pyhd8ed1ab_1 - kiwisolver=1.3.1=py39h1a9c180_1 - lcms2=2.12=hddcbb42_0 - ld_impl_linux-64=2.35.1=hea4e1c9_2 - libblas=3.9.0=8_openblas - libcblas=3.9.0=8_openblas - libffi=3.3=h58526e2_2 - libgcc-ng=9.3.0=h2828fa1_18 - libgfortran-ng=9.3.0=hff62375_18 - libgfortran5=9.3.0=hff62375_18 - libgomp=9.3.0=h2828fa1_18 - liblapack=3.9.0=8_openblas - libopenblas=0.3.12=pthreads_h4812303_1 - libpng=1.6.37=h21135ba_2 - libsodium=1.0.18=h36c2ea0_1 - libstdcxx-ng=9.3.0=h6de172a_18 - libtiff=4.2.0=hdc55705_0 - libwebp-base=1.2.0=h7f98852_2 - lz4-c=1.9.3=h9c3ff4c_0 - markupsafe=1.1.1=py39h3811e60_3 - matplotlib-base=3.3.4=py39h2fa2bec_0 - mistune=0.8.4=py39h3811e60_1003 - nbclassic=0.2.6=pyhd8ed1ab_0 - nbclient=0.5.3=pyhd8ed1ab_0 - nbconvert=6.0.7=py39hf3d152e_3 - nbformat=5.1.2=pyhd8ed1ab_1 - ncurses=6.2=h58526e2_4 - nest-asyncio=1.4.3=pyhd8ed1ab_0 - notebook=6.3.0=py39hf3d152e_0 - numpy=1.20.1=py39hdbf815f_0 - olefile=0.46=pyh9f0ad1d_1 - openssl=1.1.1j=h7f98852_0 - packaging=20.9=pyh44b312d_0 - pandoc=2.12=h7f98852_0 - pandocfilters=1.4.2=py_1 - parso=0.8.1=pyhd8ed1ab_0 - pexpect=4.8.0=pyh9f0ad1d_2 - pickleshare=0.7.5=py_1003 - pillow=8.1.2=py39hf95b381_0 - pip=21.0.1=pyhd8ed1ab_0 - prometheus_client=0.9.0=pyhd3deb0d_0 - prompt-toolkit=3.0.17=pyha770c72_0 - ptyprocess=0.7.0=pyhd3deb0d_0 - pycparser=2.20=pyh9f0ad1d_2 - pygments=2.8.1=pyhd8ed1ab_0 - pyopenssl=20.0.1=pyhd8ed1ab_0 - pyparsing=2.4.7=pyh9f0ad1d_0 - pyrsistent=0.17.3=py39h3811e60_2 - pysocks=1.7.1=py39hf3d152e_3 - python=3.9.2=hffdb5ce_0_cpython - python-dateutil=2.8.1=py_0 - python_abi=3.9=1_cp39 - pytz=2021.1=pyhd8ed1ab_0 - pyzmq=22.0.3=py39h37b5a0c_1 - readline=8.0=he28a2e2_2 - requests=2.25.1=pyhd3deb0d_0 - send2trash=1.5.0=py_0 - setuptools=49.6.0=py39hf3d152e_3 - six=1.15.0=pyh9f0ad1d_0 - sniffio=1.2.0=py39hf3d152e_1 - sqlite=3.34.0=h74cdb3f_0 - terminado=0.9.3=py39hf3d152e_0 - testpath=0.4.4=py_0 - tk=8.6.10=h21135ba_1 - tornado=6.1=py39h3811e60_1 - traitlets=5.0.5=py_0 - tzdata=2021a=he74cb21_0 - urllib3=1.26.4=pyhd8ed1ab_0 - wcwidth=0.2.5=pyh9f0ad1d_2 - webencodings=0.5.1=py_1 - wheel=0.36.2=pyhd3deb0d_0 - widgetsnbextension=3.5.1=py39hf3d152e_4 - xz=5.2.5=h516909a_1 - zeromq=4.3.4=h9c3ff4c_0 - zipp=3.4.1=pyhd8ed1ab_0 - zlib=1.2.11=h516909a_1010 - zstd=1.4.9=ha95c52a_0 - pip: - jupyterlab-vim==0.13.0 ```
The conda env for the kernel ``` name: main channels: - defaults dependencies: - _libgcc_mutex=0.1=main - attrs=20.3.0=pyhd3eb1b0_0 - backcall=0.2.0=pyhd3eb1b0_0 - blas=1.0=mkl - ca-certificates=2021.1.19=h06a4308_1 - certifi=2020.12.5=py38h06a4308_0 - cycler=0.10.0=py38_0 - dbus=1.13.18=hb2f20db_0 - decorator=4.4.2=pyhd3eb1b0_0 - expat=2.2.10=he6710b0_2 - fontconfig=2.13.1=h6c09931_0 - freetype=2.10.4=h5ab3b9f_0 - glib=2.67.4=h36276a3_1 - gmp=6.2.1=h2531618_2 - gmpy2=2.0.8=py38hd5f6e3b_3 - gst-plugins-base=1.14.0=h8213a91_2 - gstreamer=1.14.0=h28cd5cc_2 - icu=58.2=he6710b0_3 - importlib-metadata=3.7.3=py38h06a4308_1 - importlib_metadata=3.7.3=hd3eb1b0_1 - intel-openmp=2020.2=254 - ipykernel=5.3.4=py38h5ca1d4c_0 - ipython=7.21.0=py38hb070fc8_0 - ipython_genutils=0.2.0=pyhd3eb1b0_1 - jedi=0.17.2=py38h06a4308_1 - jpeg=9b=h024ee3a_2 - jsonschema=3.2.0=py_2 - jupyter_client=6.1.7=py_0 - jupyter_core=4.7.1=py38h06a4308_0 - kiwisolver=1.3.1=py38h2531618_0 - lcms2=2.11=h396b838_0 - ld_impl_linux-64=2.33.1=h53a641e_7 - libffi=3.3=he6710b0_2 - libgcc-ng=9.1.0=hdf63c60_0 - libgfortran-ng=7.3.0=hdf63c60_0 - libpng=1.6.37=hbc83047_0 - libsodium=1.0.18=h7b6447c_0 - libstdcxx-ng=9.1.0=hdf63c60_0 - libtiff=4.2.0=h3942068_0 - libuuid=1.0.3=h1bed415_2 - libwebp-base=1.2.0=h27cfd23_0 - libxcb=1.14=h7b6447c_0 - libxml2=2.9.10=hb55368b_3 - lz4-c=1.9.3=h2531618_0 - matplotlib=3.3.4=py38h06a4308_0 - matplotlib-base=3.3.4=py38h62a2d02_0 - mkl=2020.2=256 - mkl-service=2.3.0=py38he904b0f_0 - mkl_fft=1.3.0=py38h54f3939_0 - mkl_random=1.1.1=py38h0573a6f_0 - mpc=1.1.0=h10f8cd9_1 - mpfr=4.0.2=hb69a4c5_1 - mpmath=1.1.0=py38_0 - nbformat=5.1.2=pyhd3eb1b0_1 - ncurses=6.2=he6710b0_1 - numpy=1.19.2=py38h54aff64_0 - numpy-base=1.19.2=py38hfa32c7d_0 - olefile=0.46=py_0 - openssl=1.1.1j=h27cfd23_0 - pandas=1.2.3=py38ha9443f7_0 - parso=0.7.0=py_0 - pcre=8.44=he6710b0_0 - pexpect=4.8.0=pyhd3eb1b0_3 - pickleshare=0.7.5=pyhd3eb1b0_1003 - pillow=8.1.2=py38he98fc37_0 - pip=21.0.1=py38h06a4308_0 - plotly=4.14.3=pyhd3eb1b0_0 - prompt-toolkit=3.0.17=pyh06a4308_0 - ptyprocess=0.7.0=pyhd3eb1b0_2 - pygments=2.8.1=pyhd3eb1b0_0 - pyparsing=2.4.7=pyhd3eb1b0_0 - pyqt=5.9.2=py38h05f1152_4 - pyrsistent=0.17.3=py38h7b6447c_0 - python=3.8.8=hdb3f193_4 - python-dateutil=2.8.1=pyhd3eb1b0_0 - pytz=2021.1=pyhd3eb1b0_0 - pyzmq=20.0.0=py38h2531618_1 - qt=5.9.7=h5867ecd_1 - readline=8.1=h27cfd23_0 - retrying=1.3.3=py_2 - scipy=1.6.1=py38h91f5cce_0 - setuptools=52.0.0=py38h06a4308_0 - sip=4.19.13=py38he6710b0_0 - six=1.15.0=py38h06a4308_0 - sqlite=3.35.2=hdfb4753_0 - sympy=1.7.1=py38h06a4308_0 - tk=8.6.10=hbc83047_0 - tornado=6.1=py38h27cfd23_0 - traitlets=5.0.5=pyhd3eb1b0_0 - wcwidth=0.2.5=py_0 - wheel=0.36.2=pyhd3eb1b0_0 - xz=5.2.5=h7b6447c_0 - zeromq=4.3.4=h2531618_0 - zipp=3.4.1=pyhd3eb1b0_0 - zlib=1.2.11=h7b6447c_3 - zstd=1.4.5=h9ceee32_0 ```
ianhi commented 3 years ago

I've noticed this too occasinally. But I haven't been able to consistently reproduce. If you are able to consistently reproduce could you post the steps here?

As a workaround I've found that refreshing the browser page tends to fix this issue.

marvinbernhardt commented 3 years ago

Huh indeed, refreshing the browser page helps. And now I also can not reproduce it by closing tab/browser/jupyter.

ianhi commented 3 years ago

I know... This is both nice because it's easy to fix, but also terrible because it's nearly impossible to debug :(

ianhi commented 3 years ago

I think it maaaayyy be associated with running a jupyterlab build step

marvinbernhardt commented 3 years ago

I update everything weekly, so yeah, that sounds plausible. I'll let you know when it next occurs

marvinbernhardt commented 3 years ago

Just updated my system, but not conda or jupterlab extensions. Am experiencing the bug right now. Wan't me to do any diagnostics and if yes, which ones?

zaneselvans commented 3 years ago

I'm also experiencing this behavior consistently.

ianhi commented 3 years ago

@zaneselvans do you have steps to consistently reproduce?

Unfortunately I'm not really sure what the best diagnostics would be - maybe something internal to jlab about the order in which extensions load. I have some theories about things that might fix it, but I can't test them easily without being able to cause the issue to happen :(

zaneselvans commented 3 years ago

I'm not sure... I recreate my conda environment from scratch frequently though, sometimes with JupyterLab running. I didn't realize that reloading the page would fix the issue until coming across this thread. It doesn't seem like the re-build of the environment triggers it. I'll try and keep an eye out for any patterns though.

On Wed, Mar 31, 2021 at 8:46 AM Ian Hunt-Isaak @.***> wrote:

@zaneselvans https://github.com/zaneselvans do you have steps to consistently reproduce?

Unfortunately I'm not really sure what the best diagnostics would be - maybe something internal to jlab about the order in which extensions load. I have some theories about things that might fix it, but I can't test them easily without being able to cause the issue to happen :(

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/axelfahy/jupyterlab-vim/issues/31#issuecomment-811125658, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAERSN6U7MRSU3YZOUFLH43TGMYU7ANCNFSM4ZTLGT3A .

-- Zane A. Selvans, PhD Chief Data Wrangler Catalyst Cooperative https://catalyst.coop @.*** Signal/WhatsApp/SMS: +1 720 443 1363 Twitter: @ZaneSelvans https://twitter.com/ZaneSelvans PGP https://www.gnupg.org/: 0x64F7B56F3A127B04

mdeff commented 3 years ago

I'm experiencing this issue from time to time too. No jupyterlab build (using prebuilt extensions). I didn't find steps to consistently reproduce either. :/

But when I was affected, I noticed another weird behavior: redo with CTRL+r would move my cursor down multiple lines.

sid-kap commented 3 years ago

I've been getting this bug recently as well. I never noticed it before the last few weeks though... I wonder if it was introduced in https://github.com/axelfahy/jupyterlab-vim/commit/b74bb1416ac6701ff2e798c670556701837308ee?

ianhi commented 3 years ago

I'm pretty sure I was experiencing this prior to that commit but obviously can't be sure. That said I don't really see how that commit would have caused this and suspect that this was caused during the update to jlab3.

MarcoGorelli commented 3 years ago

This happens to me too, but if I use ctrl+[ instead of Esc then it works fine 🎉

somewacko commented 3 years ago

This was happening for me, refreshing didn't work. Downgrading jupyterlab_vim from 0.14.1 to 0.13.4 seems to fix it though.

It happens reliably in 0.14.1 (i.e. if I upgrade the issue comes back) but downgrading to 0.13.4 sometimes fixes it, sometimes it persists but I can fix it by refreshing the page (maybe my browser's caching something from the previous version? idk)

ianhi commented 3 years ago

In 0.14.1 somethings seems to be even more deeply broken for me. None of the vim bindings are registering at all. @somewacko can you run jupyter labextension list and report the results back here? I suspect that something is broken in the installation process and we aren't even registering the extensoin properly

In that case this isn't related to the recent extension changes, but rather to the changes in jupyter packaging that we were trying to deal with in https://github.com/axelfahy/jupyterlab-vim/pull/34. @mlucool have you been experiencing this?

somewacko commented 3 years ago

@ianhi

With 0.13.4:

$ jupyter labextension list
JupyterLab v3.0.14
/home/quasar/dev/litescraper/venv/share/jupyter/labextensions
        @axlair/jupyterlab_vim v0.13.4 enabled OK (python, jupyterlab_vim)

With 0.14.1:

$ jupyter labextension list
JupyterLab v3.0.14

So yeah, it looks like it's not registering at all in 0.14.1!

ianhi commented 3 years ago

The issues with no extension at all will hopefully be fixed by #35

ianhi commented 3 years ago

@somewacko back to the status quo of "sometimes" with 0.14.2 thanks for reporting the issue!

d-miketa commented 3 years ago

I'm still getting the bug in the latest version of Qutebrowser, but not in Vivaldi.

Edit: And I just jinxed myself and encountered the same bug in Vivaldi.

rogershijin commented 3 years ago

Disabling vimum/vimari, adding the following to the Advanced Settings/Keyboard Shortcuts, and then refreshing solved the problem for me:

{ "shortcuts": [ { "command": "notebook:enter-command-mode", "keys": [ "Shift Escape" ], "selector": ".jp-Notebook.jp-mod-editMode" }, ] }

d-miketa commented 3 years ago

Thank you @rogershijin, that setting fixed the behaviour in Qutebrowser!

marvinbernhardt commented 3 years ago

I'm having bug as before (independent of Vimium) but now it does not always go away upon refreshing the page, which makes it more annoying. Anyway, it seems that with STRG+F5 it goes away (Firefox).

ianhi commented 3 years ago

I'm having bug as before (independent of Vimium) but now it does not always go away upon refreshing the page, which makes it more annoying. Anyway, it seems that with STRG+F5 it goes away (Firefox).

I think that when you refresh you have some probability of the extensions loading in the correct order. However, if they get loaded incorrectly and then cached it's possible that your browser will reload from the cache making it impossilbe to get to the correct behavior. shift-F5/ctrl-F5 forces a reload of the cache as well and gives you a greater chance of success: https://www.debugbar.com/difference-between-f5-and-shift-f5/

realjoenguyen commented 3 years ago

This happens to me too, but if I use ctrl+[ instead of Esc then it works fine 🎉

Hey I had the same issue. While waiting for the official version fixing this bug, I work around it by this, it works.

danjump commented 3 years ago

I'm having this issue with following versions. using the ctrl+[ workaround as well, but it's not ideal. Anyone have any thoughts or status on a prospective fix here?

JupyterLab v3.1.2
~/miniconda3/envs/mydefault/share/jupyter/labextensions
        @axlair/jupyterlab_vim v0.14.2 enabled OK (python, jupyterlab_vim)
ianhi commented 3 years ago

using the ctrl+[ workaround as well, but it's not ideal.

I think the best workaround is refreshing the browser page (potentially with shift-f5) until it works and then using that session for a long time. Though obviously that is not great :(


Thoughts on what is happening

I think that there is something stochastic/async about the order in which jlab loads pre-built extensions (distributed via pip) and somehow sometimes the default shortcuts are being loaded after our shortcuts and then overwriting them. This seems to be happening even though we require the relevant extensions in our init:

https://github.com/axelfahy/jupyterlab-vim/blob/bbb7569c465e3b635f08fb4df12e05de350364dc/src/index.ts#L35 Although it's possible that the default notebook shortcuts are loaded by some other core extension (e.g. the proper notebook one, rather than the interface)

So it's probably worth opening an issue on jupyterlab's repo to discuss this, but as noted previously(https://github.com/axelfahy/jupyterlab-vim/issues/31#issuecomment-804275598) we don't have a reproducible example which will continue to make things difficult to debug.

I haven't had the time to think about this (and unfortunately won't for a bit) so if anyone does open an issue there to discuss or debugs this at all please to the issue here or update with any reproduction/debugging steps.

ianhi commented 3 years ago

ooh actually maybe one insight The async was added recently when settings were enabled. Which I missed when I said (https://github.com/axelfahy/jupyterlab-vim/issues/31#issuecomment-825314924)

https://github.com/axelfahy/jupyterlab-vim/blob/bbb7569c465e3b635f08fb4df12e05de350364dc/src/index.ts#L219


Despite my earlier claim of lack of time this is exciting and I will try to make a wheel that can be installed and then if people followin gthis can test it to confirm it works we can release a version without the async. (although if anyone else wants to do that then they are more than welcome to :))


edit:

changing that may be less simple than I'd hoped, I may end up needing to walk back claims of being able to produce a working wheel. :'( but if anyone is an async wizard please have at it.

mdeff commented 3 years ago

I think that there is something stochastic/async about the order in which jlab loads pre-built extensions.

Is it only about loading? I encountered that issue multiple times during a long session, i.e., not at the start. (Refreshing fixed it.)

ianhi commented 3 years ago

Is it only about loading? I encountered that issue multiple times during a long session, i.e., not at the start. (Refreshing fixed it.)

Interesting. I've never experienced that, only ever at the start and once I get into a "good" state where esc works it doesn't leave

mdeff commented 3 years ago

Interesting indeed. I cannot remember experiencing it from the start. I'm using Firefox.

realjoenguyen commented 3 years ago

I think the best workaround is refreshing the browser page (potentially with shift-f5) until it works and then using that session for a long time. Though obviously that is not great :(

it doesn't work in my case. I tried Ctrl+Shift+R in Mac with Chrome. I tried using Incognito mode with no extension but still nothing changes.

I tried using Safari, it doesn't have this issue anymore. But it's quite random, sometimes it works, sometimes it doesn't.

Updated: I add these settings (the one with notebook:enter-command-mode) into Advanced Settings Editor -> Keyboard Shortcuts and it fixes the issue perfectly: https://zhuanlan.zhihu.com/p/105642669

luiarthur commented 3 years ago

Disabling vimum/vimari, adding the following to the Advanced Settings/Keyboard Shortcuts, and then refreshing solved the problem for me:

{ "shortcuts": [ { "command": "notebook:enter-command-mode", "keys": [ "Shift Escape" ], "selector": ".jp-Notebook.jp-mod-editMode" }, ] }

Thanks @rogershijin! This worked for me.

KwatMDPhD commented 3 years ago

This is caused by a newly introduced default shortcut that is mapped to ESC, overwriting jupyter-vim's.

I fixed this somehow without disabling Vimari.

Here is my Jupiter shortcut setting:

{
   "shortcuts":[
      {
         "command":"kernelmenu:restart-and-clear",
         "keys":[
            "Ctrl 0"
         ],
         "selector":"[data-jp-kernel-user]:focus"
      },
      {
         "command":"runmenu:restart-and-run-all",
         "keys":[
            "Ctrl 9"
         ],
         "selector":"[data-jp-kernel-user]:focus"
      },
      {
         "command":"notebook:enter-command-mode",
         "keys":[
            "Escape"
         ],
         "selector":".jp-Notebook.jp-mod-editMode",
         "disabled":true
      }
   ]
}

Here is my Vimari setting:

{
  "excludedUrls": "localhost,tinkercad.com",
  "linkHintCharacters": "asdfjklqwerzxc",
  "detectByCursorStyle": false,
  "scrollSize": 150,
  "openTabUrl": "https://duckduckgo.com/",
  "modifier": "",
  "smoothScroll": true,
  "scrollDuration": 25,
  "transparentBindings": true,
  "bindings": {
      "hintToggle": "f",
      "newTabHintToggle": "shift+f",
      "scrollUp": "k",
      "scrollDown": "j",
      "scrollLeft": "h",
      "scrollRight": "l",
      "scrollUpHalfPage": "u",
      "scrollDownHalfPage": "d",
      "goToPageTop": "g g",
      "goToPageBottom": "shift+g",
      "goToFirstInput": "g i",
      "goBack": "shift+h",
      "goForward": "shift+l",
      "reload": "r",
      "tabForward": "w",
      "tabBack": "q",
      "closeTab": "x",
      "openTab": "t"
  }
}
nickdgardner commented 3 years ago

@KwatME Thanks! This worked for me. I'm in Chrome + Vimium, and I disabled Vimium for Jupyter lab and then added the following to my Jupyter lab keyboard shortcuts:

{ "command":"notebook:enter-command-mode", "keys":[ "Escape" ], "selector":".jp-Notebook.jp-mod-editMode", "disabled":true }

ianhi commented 3 years ago

Thanks @gofortargets for that link, that indeed looks like an effective workaround.

As for the final solution I asked about this on the jupyterlab gitter and it seems that async trickery is not the solution but instead we need to listen to the pluginChanged signal from setting registry:

https://gitter.im/jupyterlab/jupyterlab?at=6120c9f2aa48d1340c2490d2

dirkroorda commented 3 years ago

I think the best workaround is refreshing the browser page (potentially with shift-f5) until it works and then using that session for a long time. Though obviously that is not great :(

it doesn't work in my case. I tried Ctrl+Shift+R in Mac with Chrome. I tried using Incognito mode with no extension but still nothing changes.

I tried using Safari, it doesn't have this issue anymore. But it's quite random, sometimes it works, sometimes it doesn't.

Updated: I add these settings (the one with notebook:enter-command-mode) into Advanced Settings Editor -> Keyboard Shortcuts and it fixes the issue perfectly: https://zhuanlan.zhihu.com/p/105642669

Thanks. This worked for me. Refreshing did work a few times, but lately refreshing and hard-refreshing failed to solve it. But this tip worked immediately, after saving the new session the Esc behaviour is OK, without restarting or refreshing anything.

wiseyoungbuck commented 3 years ago

This issue persists to this day. Has it been raised with either the plugin make or the jupyterlab team? None of the above fixes seem to work for me either. The above shortcuts just prevent me from being able to exit the notebook cells at all with esc

ianhi commented 3 years ago

Hi @wiseyoungbuck this isn't something that the jupyterlab repo can fix it has to be fixed here as decsribed in https://github.com/jupyterlab-contrib/jupyterlab-vim/issues/31#issuecomment-903318271. I think the issue is simply that no one has been able to set aside the time to implement that fix. I will happily review any PR implementing it but don't know when I'd be able to.

None of the above fixes seem to work for me either. The above shortcuts just prevent me from being able to exit the notebook cells at all with esc

Interesting, they fixed the problem permanently for me. Would you mind posting the contents of the Shortcuts settings to this issue so we can try to debug?

gtmaskall commented 3 years ago

I'll echo I can currently reliably reproduce this. Firefox 92.0 on ubuntu 20.04 with jupyterlab_vim 0.14.5.

  1. Be in a code cell
  2. Make an edit (so in edit mode)
  3. Hit Esc
  4. Hit Enter to return to vim mode, but that vim mode is always insert - you cannot move to a different line of code.

Workaround (as stated above):

  1. After hitting Esc, move up/down to another cell
  2. Move back to original cell
  3. Hit Enter to return to vim mode, but now in command mode so you can move around and then i to insert.
wiseyoungbuck commented 3 years ago

I am presently having this issue still. It seems to only happen in Firefox. When I am using Chrome, I can use Esc to go into vim command mode and shift-esc to go into "notebook command mode", however when in Firefox Esc usually skips from insert mode to "notebook command mode".

Prior to upgrading to more recent versions of Jupyterlab, I never I always used "double escape" to reach notebook command mode and never used shift-esc. Was there a change in behavior? What I previously just exploiting a bug? Or is 'double-escape' supposed to work to go from insert mode -> command mode -> notebook cell commands?

minjae commented 2 years ago

This problem is consistently reproducible on my Chrome and Chromium setup. Refreshing (F5 or Shift + F5) helps once every 5 tries or so -- the other 4 reloaded pages exhibit the buggy behavior. The workaround quoted below fixed the issue without noticeable side effects.

@wiseyoungbuck Shift + Esc is the correct keybinding to move from Vim command mode to Jupyter mode, according to the documentation. For older versions, I too recall using Esc twice to move Vim insert mode -> Vim command mode -> Jupyter mode.

my setup jupyterlab : 3.2.1 Google Chrome 94.0.4606.61 Chromium 94.0.4606.8

Disabling vimum/vimari, adding the following to the Advanced Settings/Keyboard Shortcuts, and then refreshing solved the problem for me:

{ "shortcuts": [ { "command": "notebook:enter-command-mode", "keys": [ "Shift Escape" ], "selector": ".jp-Notebook.jp-mod-editMode" }, ] }

raffaem commented 2 years ago

Workaround:

A persistent workaround to this issue is to add the following to the Shortcuts settings (Settings > Advanced Settings Editor > Keyboard Shortcuts)

      {
         "command":"notebook:enter-command-mode",
         "keys":[
            "Escape"
         ],
         "selector":".jp-Notebook.jp-mod-editMode",
         "disabled":true
      }

as discovered from https://zhuanlan.zhihu.com/p/105642669 by @gofortargets.

This workaround does not work for me.

Jupyter-lab does not even allow me to save the snippet.

The "save" button is greyed out, and on the bottom bar it says "[additional property error] command is not valid"

ianhi commented 2 years ago

@raffaem that's meant to be added under shortcuts. So the full file should look like this:

{ "shortcuts": [
    { 
        "command": "notebook:enter-command-mode",
        "keys": [ "Shift Escape" ],
        "selector": ".jp-Notebook.jp-mod-editMode" 
    },
    {         "command":"notebook:enter-command-mode",
         "keys":[
            "Escape"
         ],
         "selector":".jp-Notebook.jp-mod-editMode",
         "disabled":true
    }]
}
raffaem commented 2 years ago

@ianhi that works, thanks. Maybe modify the first post with the full file?

ianhi commented 2 years ago

At long last I have a PR with a possible permanent fix here: https://github.com/jupyterlab-contrib/jupyterlab-vim/pull/57 :tada:

would appreciate it if other people could try it out to confirm it works.

ianhi commented 2 years ago

Just released version 0.15.0 for which this should no longer be a problem!

Huge thanks needs to go to @fcollonval without whom this probably wouldn't have been fixed

ianhi commented 2 years ago

~oh boy - but maybe old off on upgrading until we figure out #63 ~ it's been figured out - use version 0.15.1 for a fully working version

wiseyoungbuck commented 2 years ago

I'm still experiencing this problem. Even with version 0.15.1. :(

ianhi commented 2 years ago

@wiseyoungbuck can you please open a new issue complete with information on your environment. If this is continuing for you then I suspect it is a new and different cause than the one previously afflicting us

wiseyoungbuck commented 2 years ago

It may have been a version issue. I removed my Jupyterlab, and jupyterlab_vim and the problem has gone away. It has always been intermittent however, so I'll be sure to create a new issue if it comes back.