Neovim-qt: Left square bracket ([) not registered with Spanish keyboard

Created on 5 Jul 2020  路  15Comments  路  Source: equalsraf/neovim-qt

I've recently installed the latest release of neovim-qt (v0.2.16.1) and the character '[' is no longer registered when pressed. This didn't happen in my old version (v0.2.13)

I've checked to make sure it's not a plugin or remapping problem; the only factor that impacts the issue seems to be the version of neovim-qt.

  • OS: Windows
  • Spanish keyboard layout

All 15 comments

Thanks for the bug report. Do you have the ability to build neovim-qt from source?

If so, can you please provide the debug output of the non-working key sequencing with the following lines un-commented.

The code is found in Shell::keyPressEvent(...) in file src/gui/shell.cpp:

    // Uncomment for key input debugging and unit test writing.
    // qDebug() << "QKeyEvent ev:" << ev;
    // qDebug() << "  " << inp;

If you are unable to build neovim-qt from source, I can provide a Windows binary for you to download.

The input layer was overhauled recently, so it is quite possible this is a regression.

Once I have the QKeyEvent debug output, I can write tests for this scenario and fix the behavior.

I still need to work on Issue #683. However, windows does not provide a good mechanism for debug output.

I followed the compile instructions from the wiki and got the build working.

This is the message I got:

&"warning: QKeyEvent ev: QKeyEvent(KeyPress, Key_AsciiCircum, ControlModifier|AltModifier, text=\"[\")\n"
 QKeyEvent ev: QKeyEvent(KeyPress, Key_AsciiCircum, ControlModifier|AltModifier, text="[")
&"warning:    \"<^>\"\n"
    "<^>"

Let me know if I can help with anything else.

Interesting... You are being impacted by the fix for Issue #170 Pull #682.

I am not familiar with the Spanish keyboard. Could you provide some context for me as to which keys are being pressed and what you expect to occur? What happens in plain terminal nvim?

On a US Layout keyboard, the Key_AsciiCircum or ^ is associated with the key Shift + 6 key combination. With Control depressed, this key combination should trigger the alternate buffer behavior in :help CTRL-^.

The key has this behavior:

Key: `
Shift+Key: ^
AltGr+Key: [

AltGr is a weird key; sometimes it's interpreted as CTRL+ALT and I think that's the case here. This is the log for the left curly brace character '{' that is also typed with AltGr:

&"warning: QKeyEvent ev: QKeyEvent(KeyPress, Key_BraceLeft, ControlModifier|AltModifier, text=\"{\")\n"
 QKeyEvent ev: QKeyEvent(KeyPress, Key_BraceLeft, ControlModifier|AltModifier, text="{")
&"warning:    \"{\"\n"
    "{"

Maybe the fix can be something along the lines of:

if (isCaretKey && mod & ControlModifier() && !AltModifier()) {

to exclude AltGr scenario from the fix for issue #170 ?

if (isCaretKey && mod & ControlModifier() && !AltModifier()) {

Yes, we will need to do something like this.

Unfortunately, that will also introduce divergent behavior from nvim. For example, CTRL + ALT + 6 also triggers the CTRL-^ behavior in a US Layout.

It appears Qt has no abstraction for AltGr, so what you proposed may still be our best/only option...

I'd also like to write explicit unit tests that cover all cases/modifier for this key in the Spanish Layout.

Key: `
Shift+Key: ^
AltGr+Key: [

Could you confirm/provide the QKeyEvent output for all of these key sequences?

Key: ?
Shift + Key: ?
AltGr + Key: QKeyEvent(KeyPress, Key_AsciiCircum, ControlModifier|AltModifier, text="[")
Ctrl + Shift + Key: ?

Feel free to provide any other related sequences. More coverage in this area is always better.

Keys ^ and ` do not print anything on their own; they don't produce any event until you press another key you want to modify (like 'e', printing '猫' or '锚'). What I usually do is press the combination and then space (prints the symbol once) or press the same key combination twice (prints the symbol twice.)

For some reason in neovim-qt the first option (key, then space) doesn't work and prints a space. This happens on all the keys with this behavior (^, `, 麓, 篓) This looks like a different issue but I'm including the mappings for these scenarios too, just in case they are useful somehow.

Key, then Space (prints space):

QKeyEvent ev: QKeyEvent(KeyPress, Key_Space, text="`")

Key (twice) (prints symbol twice):

QKeyEvent ev: QKeyEvent(KeyPress, Key_QuoteLeft, text="`")
QKeyEvent ev: QKeyEvent(KeyPress, 0, text="`")

Shift + Key, then space (prints space):

 QKeyEvent(KeyPress, Key_Space, text="^")

Shift + Key (twice) (prints symbol twice):

QKeyEvent ev: QKeyEvent(KeyPress, Key_QuoteLeft, ShiftModifier, text="^")
QKeyEvent ev: QKeyEvent(KeyPress, 0, ShiftModifier, text="^")

AltGr + Key:

QKeyEvent(KeyPress, Key_AsciiCircum, ControlModifier|AltModifier, text="[")

Ctrl + Shift + Key:

QKeyEvent ev: QKeyEvent(KeyPress, Key_AsciiCircum, ShiftModifier|ControlModifier)

Key, then e:

QKeyEvent ev: QKeyEvent(KeyPress, Key_E, text="猫")

Shift-Key, then e:

QKeyEvent ev: QKeyEvent(KeyPress, Key_E, text="锚")

@alfredobarroso

We're headed in the right direction. The input you provided is EXACTLY what I'm looking for. The Pull Request above is my understanding of each event you described.

This is going to be tricky because the behavior you describe is not stateless like the current input design. We also need to verify Mac/Linux behave identically.

A Few Questions:

  1. Can you review the Pull Request and let me know if any events are incorrect?
  2. What should happen for Ctrl + Shift + Key?
  3. What are the preceding accent/modifier events QKeyEvents for each scenario?
  4. Are you familiar with this layout's behavior on Mac/Linux?

Thank you for the detailed responses! Your help is greatly appreciated :+1:

This sounds like a tricky scenario, yes. These keys are weird!

  1. Can you review the Pull Request and let me know if any events are incorrect?

As far as I know, it looks good.

  1. What should happen for Ctrl + Shift + Key?

Currently it seems to be

  1. What are the preceding accent/modifier events QKeyEvents for each scenario?

I don't have access to my dev computer right now so I can't check, but I remember that the control and shift keys were also logged in each relevant scenario. I think AltGr was not logged at all but not 100% sure. I'll be back home next week and will check to be sure.

  1. Are you familiar with this layout's behavior on Mac/Linux?

I'm not, but I have a Mac and a Linux machine so I definitely can check next week once I get home 馃槃

Friendly 1-week ping, let me know when those Mac/Linux machines are available for testing :smile:

I would like to understand how this behaves on those platforms before I go too far with writing a fix. Each platform handles these things differently, and that will likely influence the design.

With these input bugs the hard part is getting good accurate test coverage. Writing the fix becomes trivial after that.

Sorry for the delay, I've been away longer than I originally planned. I'll be back home on Wednesday and will work on this as soon as I arrive, promised!

Anyway I borrowed a Macbook and tested the behavior. The good news is that the 'key, then space' behavior is not broken in the Mac app.

The bad news: In the Mac keyboard there is no "Alt Gr" key, the equivalent behavior is with "Option." Option+Key doesn't work at all for any of the combinations I tried in neovim-qt, but all of them worked in terminal nvim. I don't mean only '[' but any character that requires pressing Option: @, #, [, ], {, }, none of them work :(

Would it be useful if I compile the app for Mac uncommenting the log lines and provide the logged keys for the scenarios?

Here is a more detail Windows key capture with all the modifier events and the expected output and a Mac key capture. Some of the keys in Mac worked correctly but I got no debug output.

My Linux machine is toasted, I'll try to reinstall and see if I can fix it. The behavior should be the same than Windows but if I can I'll send you another set of key events.

Windows

Key, then Space (Expected '`'):

QKeyEvent ev: QKeyEvent(KeyPress, Key_Space, text="`")
   "<Space>"

Key (twice) (Works as expected):

QKeyEvent ev: QKeyEvent(KeyPress, Key_QuoteLeft, text="`")
   "`"
QKeyEvent ev: QKeyEvent(KeyPress, 0, text="`")
   "`"

Shift + Key, then space (Expected '^'):

QKeyEvent ev: QKeyEvent(KeyPress, Key_Shift, ShiftModifier)
   ""
QKeyEvent ev: QKeyEvent(KeyPress, Key_Space, text="^")
   "<Space>"

Shift + Key (twice) (Works as expected):

QKeyEvent ev: QKeyEvent(KeyPress, Key_Shift, ShiftModifier)
   ""
QKeyEvent ev: QKeyEvent(KeyPress, Key_AsciiCircum, ShiftModifier, text="^")
   "^"
QKeyEvent ev: QKeyEvent(KeyPress, 0, ShiftModifier, text="^")
   "^"

AltGr + Key (Expected '['):

QKeyEvent ev: QKeyEvent(KeyPress, Key_Control, ControlModifier)
   ""
QKeyEvent ev: QKeyEvent(KeyPress, Key_Alt, ControlModifier|AltModifier)
   ""
QKeyEvent ev: QKeyEvent(KeyPress, Key_AsciiCircum, ControlModifier|AltModifier, text="[")
   "<^>"

Ctrl + Shift + Key (Works as expected, I think):

QKeyEvent ev: QKeyEvent(KeyPress, Key_Control, ControlModifier)
   ""
QKeyEvent ev: QKeyEvent(KeyPress, Key_Shift, ShiftModifier|ControlModifier)
   ""
QKeyEvent ev: QKeyEvent(KeyPress, Key_AsciiCircum, ShiftModifier|ControlModifier)
   "<C-^>"

Key, then e (Works as expected):

QKeyEvent ev: QKeyEvent(KeyPress, Key_E, text="猫")
   "猫"

Shift-Key, then e (Works as expected):

QKeyEvent ev: QKeyEvent(KeyPress, Key_Shift, ShiftModifier)
   ""
QKeyEvent ev: QKeyEvent(KeyPress, Key_E, text="锚")
   "锚"

Mac

Key, then Space (Works as expected):
There is no debug output

Key (twice) (Works as expected):
There is no debug output

Shift + Key, then space (Works as expected):

QKeyEvent ev: QKeyEvent(KeyPress, Key_Shift, ShiftModifier)
   ""

Shift + Key (twice) (Works as expected):

QKeyEvent ev: QKeyEvent(KeyPress, Key_Shift, ShiftModifier)
   ""

Option + Key (Expected '['):

QKeyEvent ev: QKeyEvent(KeyPress, Key_Alt, AltModifier)
   ""
QKeyEvent ev: QKeyEvent(KeyPress, Key_BracketLeft, AltModifier, text="[")
   "<A-[>"

Ctrl + Shift + Key (Not sure what to expect!):

QKeyEvent ev: QKeyEvent(KeyPress, Key_Meta, MetaModifier)
   ""
QKeyEvent ev: QKeyEvent(KeyPress, Key_Shift, ShiftModifier|MetaModifier)
   ""
QKeyEvent ev: QKeyEvent(KeyPress, Key_Escape, ShiftModifier|MetaModifier)
   "<C-S-Esc>"

Key, then e (Works correctly):
There is no debug output

Shift-Key, then e (Works correctly):
There is no debug output

By the way, in Mac no Option-key combination is working. These are the most common ones, in case it helps:

Other keys

Option + '+' (Expected ']'):

QKeyEvent ev: QKeyEvent(KeyPress, Key_Alt, AltModifier)
   ""
QKeyEvent ev: QKeyEvent(KeyPress, Key_Plus, AltModifier, text="]")
   "<A-]>"

Option + 1 (Expected '|'):

QKeyEvent ev: QKeyEvent(KeyPress, Key_Alt, AltModifier)
   ""
QKeyEvent ev: QKeyEvent(KeyPress, Key_1, AltModifier, text="|")
   "<A-|>"

Option + 2 (Expected '@'):

QKeyEvent ev: QKeyEvent(KeyPress, Key_Alt, AltModifier)
   ""
QKeyEvent ev: QKeyEvent(KeyPress, Key_2, AltModifier, text="@")
   "<A-@>"

Option + 3 (Expected '#'):

QKeyEvent ev: QKeyEvent(KeyPress, Key_Alt, AltModifier)
   ""
QKeyEvent ev: QKeyEvent(KeyPress, Key_3, AltModifier, text="#")
   "<A-#>"

Option + ` (Expected '{'):

QKeyEvent ev: QKeyEvent(KeyPress, Key_Alt, AltModifier)
   ""
QKeyEvent ev: QKeyEvent(KeyPress, Key_4, AltModifier, text="{")
   "<A-{>"

Option + 莽 (Expected '}'):

QKeyEvent ev: QKeyEvent(KeyPress, Key_Alt, AltModifier)
   ""
QKeyEvent ev: QKeyEvent(KeyPress, Key_Ccedilla, AltModifier, text="}")
   "<A-}>"

Option + 潞 (Expected '\'):

QKeyEvent ev: QKeyEvent(KeyPress, Key_Alt, AltModifier)
   ""
QKeyEvent ev: QKeyEvent(KeyPress, Key_masculine, AltModifier, text="\\")
   "<A-Bslash>"

@alfredobarroso
Sorry for the slow response... I haven't forgotten. Thanks, this is exactly what I was looking for. Most appreciated!

I will update the UTs soon with some of these scenarios. Once I have that I will come up with a strategy for supporting this keyboard layout.

Was this page helpful?
0 / 5 - 0 ratings