Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

<Alt>period no longer usable as a shortcut keybinding: <Alt>comma and <Alt>minus still work (!) #301

Closed
nickalcock opened this issue Nov 23, 2020 · 16 comments

Comments

@nickalcock
Copy link

nickalcock commented Nov 23, 2020

So I use Alt-, and Alt-. to switch between tabs. I just updated terminator from 2.0.1-49 (2af4e65) to d845e83, rebuilt gtk 3.24.23 to add wayland backend support (but still using only X11)... and now I cannot use Alt-. any more! Alt-, still works.

Rebinding keys in the GUI appears to be broken (it always ignores whatever you type and goes back to what was there before), but the wonderful not-really-documented feature that terminator picks up config file changes whenever you open the prefs pane is still working, so this isn't too much of a problem. Editing the config file by hand suggests that <alt>period does nothing and is passed through to the terminal, as is <alt>.; <alt>m works as you might expect, as does <alt>comma and <alt>minus (picked because minus is right next to period in the Gtk keynames table). This is very strange, and I have no immediate idea where to even begin hunting for a solution... I have no idea if this is terminator's fault, Gtk's fault, the tab control's fault, pygobject's fault (most unlikely, I haven't rebuilt it), Python 3's fault (ditto)... any suggestions?

(I'm using a Maltron keyboard, but this shouldn't matter as I'm going by the key-events as X sees them here. This just might explain why I find these keybindings remotely sane :) )

Many, many thanks for reviving development of the best terminal emulator ever.

@nickalcock
Copy link
Author

This is definitely not terminator. Meta_L + , produces two KeyPresses and then two KeyReleases, as expected: Meta_L + . produces a KeyPress for Meta_L, two FocusOuts, a FocusIn, a KeymapNotify, and then a KeyRelease for .: something swallows the KeyPress for .

At this point I have no idea what it might be... :(

@mattrose
Copy link
Member

mattrose commented Nov 23, 2020

that sucks. I have the same problem with some mac keystrokes. 2 things you can do. build up https://gitlab.gnome.org/GNOME/vte with debug enabled, and run the vte test app with
VTE_DEBUG=events,io vte-2.91 and see what vte is doing with your keystrokes.
The other thing you can do is install and run showkey to tell you what the keycodes are https://www.geeksforgeeks.org/showkey-command-in-linux-with-examples/

@nickalcock
Copy link
Author

I did an xdotool key "XF86LogGrabInfo", which tells me it's either lxqtglobalkeysd or fvwm, neither of which have changed in ages -- but fvwm is grabbing ., albeit with a completely different modifier key engaged. I'll try disabling that shortcut (I never use it) and try again.

I released the keybinding... and fvwm has still grabbed the key. I guess I'll have to restart, and/or possibly try upgrading: this more or less has to be a fvwm bug, I think, unless X is doing something very odd and giving fvwm the grab even when it didn't ask for it. (It does seem to have an awful lot of grabs registered...)

@nickalcock
Copy link
Author

nickalcock commented Nov 23, 2020

... oh wait, I have upgraded vte recently (long enough ago that I forgot I'd done it, but recently enough that I hadn't restarted terminator since then). I bet that's the culprit... a jump from 0.60.2-4 to 0.62.1-2 is quite big enough to break stuff :) looking at it...

... no that can't be it, I forgot that the keybinding is broken in konversation too. But it's worth a look anyway.

@nickalcock
Copy link
Author

As expected, vte never sees it: 'Focus out / Focus in'.

Time to start reverting things to see what recent change this might be: thankfully nearly all my recent stuff (python 3, terminator, vte) is already ruled out, and I haven't touched X :) we're almost left with the kernel or nothing...

@mattrose
Copy link
Member

VTE does have a bad habit of handing off keypresses to the GTK Input Manager and not doing anything with them. and now I should go back down to my linux box and see if I can reproduce the problem.

If you build vte with the debugging enabled, it should tell you.

btw, are you still using fvwm? Last time I used that was literally sometime in the mid 90s.

@nickalcock
Copy link
Author

That's when I started using it. I'm still using the same config and nearly the same version :) I keep meaning to look at awesome, but time is always short...

I strongly suspect that this is being grabbed by something else (likely fvwm), or a new kernel (the largest recently upgraded component, 5.9.6 -> 5.9.10) has changed the input layer such that the key is being mistaken for another one which fvwm is grabbing. (fvwm was grabbing Hyper_L+period, which is actually the PrtSc key plus period... but now it's not, and that is getting through to vte as a centered period. Only... Alt-. is still not getting through. Well, OK, again on my keyboard that's left-windows-key+period: modifier mapping is Meta_L, i.e. Alt in most programs' parlance.)

@nickalcock
Copy link
Author

VTE with debugging enabled simply says 'Focus out / Focus in'. No mention of keys being hit. It's being eaten before it gets that far :(

@mattrose
Copy link
Member

Hmm, when I run the vte test app that I built with debug enabled I get the following

Keypress, modifiers=0x0, keyval=0xffe9
Match hilite update (378, 135) -> 54, 11
Keypress, modifiers=0x8, keyval=0x8be
Keypress, modifiers=0x8, keyval=0x8be, cooked string=`≥'.
Outgoing buffer written len = 0x1 = 1
00000000  1b                                                 |.               |
Outgoing buffer written len = 0x3 = 3
00000000  e2 89 a5                                           |...             |
::pty_io_read condition 03
read 39/25855 bytes, again? yes, active? yes
::pty_io_read condition 01
read 39/25855 bytes, again? yes, active? no
Handler processing 39 bytes over 1 chunks.
Processing data syntax 0 chunk 0x7f86430f2000 starting at offset 1
Incoming buffer len = 0x27 = 39
00000000  07 1b 5b 37 6d 3c 66 66  66 66 66 66 66 66 3e 1b   |..[7m<ffffffff>.|
00000010  5b 32 37 6d 1b 5b 37 6d  3c 66 66 66 66 66 66 66   |[27m.[7m<fffffff|
00000020  66 3e 1b 5b 32 37 6d                               |f>.[27m         |
read 39 bytes, chunk finished, data syntax now 0

You might be right about something else eating it

@mattrose
Copy link
Member

I'm building vte with meson -Ddebug=true build && ninja -C build and then running VTE_DEBUG=events,io ./build/src/app/vte-2.91

@nickalcock
Copy link
Author

Confirmed: tearing all keybindings featuring period out of fvwm and restarting fixes everything. I guess fvwm must be grabbing everything featuring period, and then for reasons that remain opaque to me failing to hand this particular one on. All of a sudden. Even though I last rebuilt it in 2019 and last gave it a nontrivial update in 2011.

I suspect it might be hard for me to track this one down, but it's definitely not terminator, which remains a flawless jewel of oh wait I should raise some pull requests

@nickalcock
Copy link
Author

btw I will be holding this bug up as an exemplar of how bug reports should be responded to (even when they are useless bug reports that aren't even about your software), and try to follow the lessons you have taught about good bug response better myself. :)

@nickalcock
Copy link
Author

... no wait. I wrote that, switched away... and the keybinding vanished again!!! While X was running. Mystery unsolved, analysis continues... will restart the usual sessionful of apps very slowly and test between each one.

@nickalcock
Copy link
Author

nickalcock commented Nov 24, 2020

Got it. In an obscure virtual machine that exists only to connect to work's VPN and run Konversation and Firefox, and which upgraded itself to Plasma 5.19.x only last Sunday (and which was concealed from the grabs dump because it was connecting over a TCP connection and the grabs dump errored out rather than dump any of those), is this little gem in .config/kglobalshortcutsrc, which is consulted and respected whenever any KDE application starts:

[org.kde.plasma.emojier.desktop]
_k_friendly_name=Emoji Selector
_launch=,Meta+.,Emoji Selector

UGH NO. All keybindings in that file aggressively changed to None, dammit. Will report bug to KDE (because it is a bug: that shortcut was assigned without noticing that I was using it in KDE applications that suddenly could no longer see the key because an emoji selector I didn't even have installed was stealing it.)

@mattrose
Copy link
Member

mattrose commented Nov 24, 2020

btw I will be holding this bug up as an exemplar of how bug reports should be responded to (even when they are useless bug reports that aren't even about your software), and try to follow the lessons you have taught about good bug response better myself. :)

Thank you so much 😊 It was an opportunity for me to dig into some debugging methods I found handy in the past, refresh my memory of them and demonstrate how to use them. Even though the bug is closed, this is still now out there on the internet and searchable by google 😃 You never know what people will come across.

I try to be welcoming as I can, and someone such as yourself, with a willingness to work with another person to track down an issue, is also invaluable.

@nickalcock
Copy link
Author

Well, it was getting in the way of my job so I could hunt without too much guilt, plus I still managed to get some code written yesterday because thank goodness Emacs lets you hit ESC . if M-. has been stolen by some evil global shortcut program :)

This is https://bugs.kde.org/show_bug.cgi?id=429589 now. It's even more of a bug than I thought it was: kglobalaccel steals the keybinding globally even if the thing it's assigned to invoke is not installed, then throws the key away! That can't be right.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants