Entering vi(1) commands in JupyterLab notebooks causes scroll to bottom of cell ...

[nmvega]

Hello Friends:

I originally posted the following here, and they suggested posting this issue here.

I'm running the below library versions in a Python virtual environment.

My JupyterLab Notebooks use vim(1) emulation.

I don't know when this problem started, but every time I perform, say, a w! editor operation to save changes, the Notebook scrolls to the bottom of the current input cell, but doesn't go back up to the cursor input location so that I can continue working. I have to scroll back up each time and find where I was.

The behavior use to be a convenient and quick appearance of the ed(1) one-line editor at the bottom of the display as you typed a vi(1) command, then it would disappear and you were taken back to your cursor. It no longer does that.

Can anyone suggest what to check for and/or how to fix this?

Thank you in advance! (See below).

Python 3.12.4
jupyter==1.0.0
jupyter-console==6.6.3
jupyter-events==0.10.0
jupyter-lsp==2.2.5
jupyter_ai==2.18.1
jupyter_ai_magics==2.18.1
jupyter_client==8.6.2
jupyter_core==5.7.2
jupyter_server==2.14.1
jupyter_server_terminals==0.5.3
jupyterlab==4.2.3
jupyterlab-vim==4.1.3
jupyterlab_pygments==0.3.0
jupyterlab_server==2.27.2
jupyterlab_widgets==3.0.11

[nmvega]

Hello Friends:

I originally posted the following here, and they suggested posting this issue here.

I'm running the below library versions in a Python virtual environment.

My JupyterLab Notebooks use vim(1) emulation.

I don't know when this problem started, but every time I perform, say, a w! editor operation to save changes, the Notebook scrolls to the bottom of the current input cell, but doesn't go back up to the cursor input location so that I can continue working. I have to scroll back up each time and find where I was.

The behavior use to be a convenient and quick appearance of the ed(1) one-line editor at the bottom of the display as you typed a vi(1) command, then it would disappear and you were taken back to your cursor. It no longer does that.

Can anyone suggest what to check for and/or how to fix this?

Thank you in advance! (See below).

Python 3.12.4
jupyter==1.0.0
jupyter-console==6.6.3
jupyter-events==0.10.0
jupyter-lsp==2.2.5
jupyter_ai==2.18.1
jupyter_ai_magics==2.18.1
jupyter_client==8.6.2
jupyter_core==5.7.2
jupyter_server==2.14.1
jupyter_server_terminals==0.5.3
jupyterlab==4.2.3
jupyterlab-vim==4.1.3
jupyterlab_pygments==0.3.0
jupyterlab_server==2.27.2
jupyterlab_widgets==3.0.11

BUMP. Can anyone take a look at this please? Thank you.

[firai]

Thanks for reporting. As suggested in the original issue you filed, have you confirmed whether it's an issue upstream with replit/codemirror-vim, using their sandbox at https://raw.githack.com/replit/codemirror-vim/master/dev/web-demo.html?

[nmvega]

Hi @firai Thank you for replying. I visited the sandbox URL you provided above, and the :w <enter> experience in it is perfect; and is the same experience I used to have in my Notebooks. I don't know what changed. I'm using this library for vim: jupyterlab-vim==4.1.3. I'm unsure what to try next.

[firai]

After :w and pressing enter, if you press j or k, does the view scroll up to the cursor, or has the cursor moved or has the cell de-focused for you?

You said that "the behavior [used] to be a...one-line editor at the bottom of the display as you typed [an ex] command, then it would disappear and you were taken back to your cursor. It no longer does that." Are you saying that you're also seeing a problem with the ex prompt, or just the scrolling issue?

To make sure we're talking about the same issue, would it be possible for you to record a GIF of the problem you're seeing?

[nmvega]

@firai After reading your reply, let me clarify what I wrote (because I mis-remembered how it used to work until I saw the sandbox today ). 😊

When things worked for me, it worked just like the sandbox does. That is, when typing :w, an ex line editor opened in-place (always right where the cursor was), with absolutely no scrolling whatsoever (neither down nor up); no matter how vertically talk the cell happened to be.

Now, for some odd reason, my cursor jumps to the bottom of the cell when typing w:, no matter how tall or short the cell is. It's just less noticeable when the cell is not very tall (like, for example, one with a few Python import statements).

But, scrolling to the bottom of a cell is the wrong behavior. As with the sandbox, it shouldn't seek to scroll to the bottom of a cell under any circumstance, but that's what mine is doing now. Each time it does this, I must mouse-scroll back up to my edit location. Annoying because I like to save early & often. LoL 😄

I hope that helps. And thank you.

[nmvega]

PS: I noticed the GIF request too late. Let me know if you still need it after my reply, and I'll be happy to furnish one.

[firai]

Thanks for the clarification. It seems like you may be comparing JupyterLab/jupyterlab-vim, which does not limit the height of the input area and therefore scrolls the document panel outside of the input area as necessary, against the codemirror-vim sandbox behavior when the input area height is limited and scrolling happens within the input area.

When the input area height is limited to be shorter than the visible page height and scrolling only happens within the input area, the ex prompt neatly displays without scrolling in the sandbox as you have mentioned.

However, when the height of the input area is longer than the visible page height, which is how very long cells are set up in JupyterLab, the sandbox page scrolls to the bottom of the input area to show the ex prompt and the cursor is no longer visible after exiting the prompt. This is the same behavior that you're seeing in JupyterLab/jupyterlab-vim.

This is the behavior that I'm seeing in JupyterLab/jupyterlab-vim.

I understand your frustration though. Just thinking out loud, it may not be possible to show the ex prompt without scrolling to the bottom of the input area if the cell height isn't limited. It may be possible to force the document to scroll/focus back up to the cursor after exiting the ex prompt, but this probably needs to be implemented upstream in codemirror-vim.

[nmvega]

@firai What would be do without GIF animations. 😊 Thank your for the comprehensive reply.

In your sandbox trials, can you enable the status bar option at the top and try again? (like in the screenshot below). Below is a screenshot of what I see with that enabled. (Apologies for having trouble creating a GIF because I'm currently booted to Fedora with Wayland, and many capture tools don't yet support Wayland).

Although difficult to spot, when I issued the :w command, the edit-cursor is located on line-7 (beneath the "hi") .

That behavior would be good. It's not in-place (and probably never was LoL) but it doesn't scroll either.

[firai]

Unless you're talking about different JupyterLab behavior than what I have shown above (again, recording a GIF would help here), it doesn't seem like turning on the status bar would help here. It seems like you're still looking at the sandbox behavior when the CM editor is shorter than the visible page, and the scrollbar is inside the CM editor. In order to be comparable to the JupyterLab behavior, you need to resize the CM editor in the sandbox to be taller than the page (using the drag control at the bottom right of the CM editor), such that the bottom of the CM editor is below the visible page, and the page has a scrollbar outside of the CM editor itself.

EDIT: By the way, obviously, the other solution to this problem is to make sure you don't have very tall cells, such that the bottom of the input area can be visible at the same time as the line where the cursor is.

[wxie2013]

being annoyed by the same issue here. I'm now trying to have myself used to "ctrl-s" instead of "w" even in the vim mode.