Bug report: vim search mode would leak delete key

[LumenYoung]

As suggested in the title, I find this potential bug, and it is easy to reproduce on my side

1. enable vim mode
2. type / to enter search mode
3. enter random characters and then backspace to simulate a deletion

Expected behavior: the character in search should be delete

Current behavior: the searched content is not deleted, rather the character under the cursor is deleted.

SB Version: 0.8.1

[erinsummer]

I'm able to reproduce this in 0.9.0 as well.

I'm seeing the issue any time the cursor is supposed to be focused in the vim command line. I thought perhaps it was related to one of my (many) browser extensions, but after disabling them all the input focus shift persists.

Specifics:

• SB: 0.9.0
• Debian GNU/Linux 11 (bullseye) 5.10.221-1
• via SSL/nginx (no proxy)

1. enable vim mode
2. use a vim motion (select some text, start a search, anything to open the command editor). I was trying to do a find/replace using :s%, and kept making typing errors. Arrow keys, backspace, and maybe some other keys seem to be sent back to the editor rather than the vim command line
3. Escaping out of the vim command leaves one with whatever changes were made by the keystrokes being passed through to their document instead of their vim command prompt

Expected: send the keystrokes to the (focused) vim command prompt rather than the main editor itself

[meain]

Probably related. I've had cases where when I press G to go to the last line in normal mode, it would just enter that into the editor.

[lutzky]

Silverbullet is based on codemirror, but this demo doesn't have this bug: https://codemirror.net/5/demo/vim.html. That demo is for an older version though.

[lutzky]

This broke the Enter key in insert mode for ordinary paragraphs. Workaround: Go back to command mode and hit o.

I think this is caused by https://github.com/replit/codemirror-vim/issues/182.

[LumenYoung]

Thanks a lot @lutzky for the long waited fix! I've tested the latest commit and it works on my instance.

But one thing I still find not really reasonable for a long term vim user is the del key in the normal mode still deletes in the original text instead of just moving backward. I think it is pretty annoying and not intended for vim usage.

Do you see a way to make this behavior consistent with vim's behavior? Technically it doesn't belongs to this bug but I would assume these are relevant and could be fixed with similar manner.

[lutzky]

@LumenYoung interesting, I hadn't noticed that. This cannot be fixed in the same manner as it reproduces in the codemirror-vim demos (v5, v6). Interestingly, I don't see this posted on https://github.com/replit/codemirror-vim/issues?q=is%3Aissue+delete.

[LumenYoung]

@LumenYoung interesting, I hadn't noticed that. This cannot be fixed in the same manner as it reproduces in the codemirror-vim demos (v5, v6). Interestingly, I don't see this posted on https://github.com/replit/codemirror-vim/issues?q=is%3Aissue+delete.

Ah, thanks for the knowledge. Emm, this is pretty annoying and I will file a report to the codemirror team. I think these kind of problem really gives me a sense of unstability when writing on the silverbullet but with your patch it is already getting better. Thanks!

[LumenYoung]

@LumenYoung interesting, I hadn't noticed that. This cannot be fixed in the same manner as it reproduces in the codemirror-vim demos (v5, v6). Interestingly, I don't see this posted on https://github.com/replit/codemirror-vim/issues?q=is%3Aissue+delete.

Hey @lutzky, I've tried the v6 demo here https://raw.githack.com/replit/codemirror-vim/master/dev/web-demo.html and I can't reproduce this problem. Can you verify again that you can delete the character in normal mode when hovering above them and hit del key? I think the vim mode on both v5 and v6 demo are behaving correctly.

[lutzky]

Loading the page, and hitting (in Command mode) Down-Down-Right-Right-Del indeed deletes the (p) character at that location.

[LumenYoung]

Loading the page, and hitting (in Command mode) Down-Down-Right-Right-Del indeed deletes the (p) character at that location.

Hey, @lutzky sorry for the late reply as I forgot about this thread for a long time. Indeed I can replicate the problem of leaking del at the demo editor but the demo feels more solid than silverbullet's one since it doesn't leak space key in the normal mode.

I think del would be somewhat not very common to touch during the daily typing but space as a very large and very commonly touched key and is therefore rather more troublesome when it violates the vim behavior in silverbullet. I wonder if you see this as a bug in the silverbullet?

[lutzky]

Hmm, I just realized something odd: The behavior is identical to neovim's default config! nvim -u NONE loads neovim without any settings or plugins, and:

• Hitting space in normal mode moves the cursor one character forward
• Hitting delete in normal mode deletes the character at the cursor (like insert mode)

So silverbullet appears to be doing the right thing here.

[LumenYoung]

Hmm, I just realized something odd: The behavior is identical to neovim's default config! nvim -u NONE loads neovim without any settings or plugins, and:

* Hitting `space` in normal mode moves the cursor one character forward

* Hitting `delete` in normal mode deletes the character at the cursor (like insert mode)

So silverbullet appears to be doing the right thing here.

Hi Lutzky. I happen to be using neovim. Although in normal mode the space does move the cursor a character forward, it doesn't insert any space under cursor. This is what Silverbullet does wrong. The same behavior mismatch also happens at the key Enter, which would move the cursor to the next line if correctly behaving at neovim but it also inserts the linebreak in the silverbullet. So I think it still counts as bug because I can't reproduce both of the behavior in code mirror demo.

[lutzky]

Hmm, Silverbullet doesn't insert a space in normal mode in vim for me. Double-checked on silverbullet.md. In the attached video, I'm only pressing spacebar (demonstrating difference between normal and insert mode).

Screen recording 2025-01-09 9.46.58 AM.webm