editorTextFocus issue?

@Tyriar As @tecosaur mentioned here, the issue does not reproduce on Linux, suggesting that it's a Mac problem. The first possibility that came to mind was that editorTextFocus may not be disabling the shortcut as it should when the editor does not have focus.

@janosh with just plain vscode, have you tried adding something like

{
  "key": "cmd+v",
  "command": "editor.action.addCommentLine",
  "when": "editorTextFocus"
}

to your keybindings.json? I think that would provide a rather useful result, and maybe a more minimal MWE.

@tecosaur Good call! That works as expected. So not a problem with editorTextFocus and not a MWE, I'm afraid.

Still, even in an empty project (i.e. no config) and with all other extension disabled, as soon as I enable LaTeX Utilities, I can no longer shortcut paste (right click to paste still works) in the integrated terminal or in search inputs. With only LaTeX Workshop enabled, the problem is gone. So maybe it's LU after all?

To me this just seems odd.
Since it looks like editorTextFocus by itself works, I would expect editorTextFocus && editorLangId == 'latex' && config.latex-utilities.formattedPaste.useAsDefault to be false whenever editorTextFocus is.

As long as that a && b && c statement works as expected, I then wouldn't expect this keybinding to have any effect on pasting outside the 'main' editor.

Could you try removing that keybinding statement from the package.json in your installation and seeing if it fixes it?

• If it doesn't that it's almost certainly LU.
• However if it does fix it then it still looks like a vscode issue (to me).

In ~/.vscode/extensions/tecosaur.latex-utilities-0.3.3/package.json, I commented out

"keybindings": [
	// {
	// 	"key": "ctrl+shift+v",
	// 	"mac": "cmd+shift+v",
	// 	"command": "latex-utilities.formattedPaste",
	// 	"when": "!config.latex-utilities.formattedPaste.useAsDefault && editorTextFocus && editorLangId == 'latex'"
	// },
	// {
	// 	"key": "ctrl+shift+v",
	// 	"mac": "cmd+shift+v",
	// 	"command": "editor.action.clipboardPasteAction",
	// 	"when": "config.latex-utilities.formattedPaste.useAsDefault && editorTextFocus && editorLangId == 'latex'"
	// },
	// {
	// 	"key": "ctrl+v",
	// 	"mac": "cmd+v",
	// 	"command": "latex-utilities.formattedPaste",
	// 	"when": "config.latex-utilities.formattedPaste.useAsDefault && editorTextFocus && editorLangId == 'latex'"
	// }
],

and that solved the issue. After reloading VS Code, cmd + v worked again everywhere even with LU enabled.

One thing I should have mentioned earlier (but forgot) is that with LU enabled, the context menu shows that pasting is remapped to cmd + shift + v (that was before commenting out the "keybindings").

In that case, I return to suspecting vscode. Based on what you said about the context menu saying that remapping has occurred, perhaps the keybindings parser identifies the remapping and applies it globally (i.e. ignoring the when). That's just speculation though, I'll leave the detailed diagnosis to those working on vscode who have to fix it.

Oh @janosh, a separate MWE to try, how about just adding this to your user keybindings (and no LU etc.)

{
  "key": "cmd+shift+v",
  "command": "editor.action.clipboardPasteAction",
  "when": "editorTextFocus"
},
{
  "key": "cmd+v",
  "command": "editor.action.addCommentLine",
  "when": "editorTextFocus"
}

Both keybindings work as expected in the editor and, more importantly, the remapped clipboardPasteAction applies to the integrated terminal and search inputs as well which I assume is unexpected behavior. With only addCommentLine

// {
//   "key": "cmd+shift+v",
//   "command": "editor.action.clipboardPasteAction",
//   "when": "editorTextFocus"
// },
{
  "key": "cmd+v",
  "command": "editor.action.addCommentLine",
  "when": "editorTextFocus"
}

pasting in terminal and search is back to cmd + v.

Fantastic! I think we've narrowed down on the issue at hand.

Keybinding remapping is applied beyond the specified scope ("when":)

I'd consider updating the title and MWE on your initial comment at this point.

Nice analysis! The root cause is:

{
	"key": "ctrl+shift+v",
	"mac": "cmd+shift+v",
	"command": "editor.action.clipboardPasteAction",
	"when": "config.latex-utilities.formattedPaste.useAsDefault && editorTextFocus && editorLangId == 'latex'"
}

This makes our reverse lookup for editor.action.clipboardPasteAction believe that cmd+shift+v is the preferred key combination (it appears "later" in the keybindings list). So that's why the Edit menu at the top will most likely render cmd+shift+v next to the Paste action for you. That, by itself, is pretty reasonable...

But the unreasonable thing is how Paste actually works on macs in other inputs than the editor. Basically, cmd+v doesn't do anything on macs in Electron. The only reason cmd+v pastes in the terminal or the find input is because we display cmd+v next to the Paste action in the top level menu, and then cmd+v is captured by the top level menus (outside of our keybindings story), which end up dispatching the editor.action.clipboardPasteAction action to the renderer. That action is pretty nice and checks if an editor has focus, and if not, it invokes the corresponding command on the native inputs here

I have encountered this before and I thought it is so rare that it doesn't warrant further workarounds from us... See #74599 (comment)

But now I think we should perhaps add some workaround specifically for this case... Perhaps we should always consider cmd+v as the preferred keybinding for editor.action.clipboardPasteAction

The minimal repro would be in keybindings.json:

{
	"key": "alt+w", // something else than cmd+v
	"command": "editor.action.clipboardCopyAction",
	"when": "textInputFocus" // anything actually
}

@alexandrudima from what you've said, I understand that vscode captures the shortcut, and then tries the highest priority keybinding. Correct?

Would a decent approach be tweaking the behaviour such that if the "when" condition on the highest priority keybinding fails, the second-highest is tried etc.?

Normally, if you look at our keybindings.json we don't have any keybindings for paste outside of a code editor. Search for "cmd+v" without a "when" condition, there is no rule... So normally our keybinding dispatching does not interpret cmd+v, we leave the keybinding to fall through and we leave Electron to do something there... (for <input>s)

On Windows and on Linux, our lack of a keybinding results by default in Electron generating a paste event in the <input>s and pasting. On mac there is simply no paste event happening by default...

On top of this, the mac has a weird twist. When we render a keybinding in the top level menu, this is not only rendering it... The OS dispatches keybindings to the menu directly... In fact, we don't even get the keybinding anymore... You can notice this by seeing a blue flash in the menu... If we render anything in the menus, pressing that key combination will result in Electron/the OS interpreting and capturing that and converting that into a menu invocation... So when we render cmd+v next to the Edit > Paste menu, pressing cmd+v does not reach us. We only get to know that Edit > Paste was invoked... We don't even get to know (this might be an Electron limitation) if it was clicked via the mouse or the displayed keybinding was pressed.

Anyways, the mac menu is weird, the default cmd+v is missing on the mac and the way pasting in native inputs works today is too brittle. I will probably add another set of keybindings to capture cmd+v/cmd+c/cmd+x for simple <input>s and execute paste/copy/cut...

That should result in things working even when cmd+v is no longer displayed in the menus, because then our keybinding dispatching will dispatch those...

Huh. This all sounds like a huge hassle/mess. After reading that I'm quite happy just dealing with my nice little extension without having to deal with that headache 😃

Anyway, thanks for looking at this, and best of luck!