So, the current GTK2 package in the MSYS2 repository includes patches from the referenced bugs that should've fixed this issue. But they did not. Their author did a great job by fixing those bugs and also devoted some time to [investigating this issue](https://bugzilla.gnome.org/show_bug.cgi?id=768722#c50) with Geany. It is clear to me now that this is not a GTK problem, but a broken Geany implementation. I'll explain.
Geany hotkeys are handled in two places: First, they are manually handled in `on_key_press_event()`, and this is the part that is implemented wrong, it checks for layout-dependent `event->keyval`. Then, if a hotkey is not detected there, the handling goes to GTK's menu accelerators, and this is the part, why it sometimes work, because some hotkeys are bound to menu items, and GTK implements hotkeys right, in layout-independent way, so bound hotkeys work, but with some specifics: they work only when the item that corresponds to the hotkey is not grayed out (disabled). And when you open the Edit menu, Geany decides to enable or disable the Copy Ctrl+C menu item based on the existence of any selection in the textarea. You open the Edit menu when nothing is selected - Ctrl+C stops working, you select something and open the menu - Ctrl+C works again. This explains why it reproduces "randomly". Another confirmation of this theory was to find a hotkey that is not bound to a menu item, I found "Go to matching brace" \<Primary>b, and indeed, it doesn't work in an alternative layout, and if I change the hotkey to the same key in an alternative layout, it stops working in English layout. Now, when everything is clear, I hope you'll find some time to fix this. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1368#issuecomment-273678207
