bug: neovim extension blocks ctrl+w binding for kill-word in terminal

[bpkroth]

Did you check docs and existing issues?

• I have read all the vscode-neovim docs
• I have searched the existing issues of vscode-neovim
• I can reproduce the issue with an empty init.vim/init.lua and no other vscode extensions (when applicable)

Neovim version (nvim -v)

v0.9.1

Operating system/version

Windows

Describe the bug

neovim vscode extension adds various "ctrl+w" bindings that have a "!editorTextFocus" when clause that cause "ctrl+w" in "terminalFocus" mode to match and block the standard bash "kill-word" binding for deleting words with "ctrl+w"

Attempting to add the clause doesn't seem to work for me. Only disabling the extension makes a difference.

Steps To Reproduce

1. Install Neovim VSCode Extension
2. Open a terminal in vscode
3. Type something (e.g. "abcd efgh")
4. Attempt to use "Ctrl+w" to delete the second word.
5. Notice a "Waiting for 1 second for additional chord key" message in the bottom status bar.

Expected Behavior

Ctrl+w should be passed through to the terminal.

[theol0403]

@martin-braun could you look into this?

#1248

[theol0403]

As a workaround, you can delete those bindings in keybindings editor.

[martin-braun]

@theol0403 I guess that's the price to pay for treating the terminal like a buffer eh .. Neovim has terminal mode, we don't.

If we exclude ctrl+w in the terminal panel, we won't be able to navigate out of it.

We could shift back to my original idea to treat the terminal like a tmux window and use ctrl+b to enter/leave it. I'm not aware of any other possibility right now.

Thoughts?

cc @justinmk

[theol0403]

Ah, I assumed that for now we excluded ctrl+w in the terminal panel, and can't nagivate out of it. I guess I missed that we don't.

I think ctrl+b is a little too opinionated, but those bindings would go well in the wiki.

We should just disable ctrl+w in the terminal pane.

[tanmng]

+1 on this.

I think it was ill-conceived idea to actually hijack the ^+W key combination, while it's such a common thing to press in a shell.

Even worse, the combinations were set for when the focus is not on the editor (ie. when you are focusing on the terminal panel of VS Code), and transfer the focus to the editor - ie. taking you away from the terminal.

[martin-braun]

@tanmng

I think it was ill-conceived idea to actually hijack the ^+W key combination, while it's such a common thing to press in a shell.

This totally went over our head.

Even worse, the combinations were set for when the focus is not on the editor (ie. when you are focusing on the terminal panel of VS Code), and transfer the focus to the editor - ie. taking you away from the terminal.

That was kinda the idea behind it though, we just didn't foresee the conflict. Neovim doesn't have the problem with terminal mode, something we cannot leverage (yet).

@theol0403

I think ctrl+b is a little too opinionated, but those bindings would go well in the wiki.

Oh yes, it was late yesterday. I forgot that it will also not work like one might expect when having the terminal on the right side.

We should just disable ctrl+w in the terminal pane.

So keeping the navigation, but excluding the terminal pane. We will end up with a one-way street. It would be great to have a binding that always jumps to the first editor group, so that you can exit the terminal pane.

Thoughts?

[theol0403]

Agreed. I think the one-way street is the only option, and it's what I was thinking it was when I merged (my bad).

If we can find a nice binding to exit, that would be ideal, but nothing comes to mind. Maybe ctrl+escape or something? Still seems too opinionated.

[martin-braun]

@theol0403 The exit keybinding for Neovim's terminal mode comes into mind <C-\> which is unfeasible for most locales.

I still believe hijacking ctrl+b would be a good option, think about it: ctrl+b was chosen by tmux, because it was not taken for significance and it is recognized by most other environments as possible collision candidate. It has to do with pane and window navigation and we are in a safe environment where tmux cannot collide with us. It's basically welcoming at this point.

We would have our prefix for #1252. ctrl+b is mapped to moving left one character in the terminal. Nobody ever cared about tmux overriding it, because arrow keys are easier to press than ctrl+f/ctrl+b, so why would we care?

ctrl+b is not used by VSCode anywhere. It seems like a sane default, even if it's not part of the Neovim spec, I'd like to vote for it.

[theol0403]

@martin-braun I think I'm sold! We just need an configuration option for it.

[martin-braun]

@theol0403 Great, but I need to come up with some sane defaults. The challenge is that the terminal can live at the left, right or bottom of the screen and the splits and navigation directions are predetermined by VSCode depending on its position.

For now, I implemented your idea of <C-ESC> to leave Terminal focus, it's a good one, so we can merge for now and get rid of this issue. See #1300.

I will come up with some defaults next week and propose those over at #1252.

Thank you.

[justinmk]

I still believe hijacking ctrl+b would be a good option

ctrl+b is also a readline binding, which I use. So it has the same issue as ctrl+w.

[martin-braun]

@justinmk how so, for me ctrl+b moves the cursor to the left, at least in zsh shell. Could you please elaborate?

[justinmk]

Yes, I use it to move the cursor in bash.

[martin-braun]

@justinmk I think the only reasonable solution would be to have a prefix configuration in the settings, so that you could change it without remapping tons of key bindings.

"Panel Navigation Prefix" or something along those lines.

[theol0403]

@martin-braun I don't think we can have the prefix as a variable. It would have to just be enable/disable.

[justinmk]

keybindings are already configurable, could just document how to override these particular keybindings.

[bpkroth]

FYI, #1558 from the latest release (1.0.0) seems to have broken this again.
Reverting to 0.9.1 restores the expected terminal behavior.

[xiyaowong]

It's this #1257 that caused the problem.