@Forkest first thing, thanks a lot for the time and effort you put into this, which lead to understanding the issue a lot better, that's awesome. Same goes to LRN.

Also one of the contributors had a first look at accelerators and came upon the stumbling block that they only allow one closure per binding, not sure if they found any workaround to that.

Well. Actually, do we even need that? I mean, I don't see any actual use for binding more than one think to the same key from the user point of view: there is no way for the user to know when which would be activated, it solely depends on how the handler is implemented, and nothing exposes that to the user. So if it's a mere internal, we could likely just have an internal handler list we activate in order when the "single" keybinding handler is called. If we really do need this multi-handler thing in the first place.

Yes, the issue here is really not trivial, because keybinding handling in Geany has a fair share of subtleties (not to say "weirdness"), but some are important (like the VTE part).
But, just as you are, I'm not very fond of Geany's keybinding handling. I'm not either fond of changing something so fundamental when it works; but apparently it's actually not working properly.

So IMO we should consider the two possible solutions: fix our code (if that's even doable), or switch to the "proper" GTK methods for handling keybindings.

Since the keybinding activates the menu making it inactive is what stops it trying to copy when there is nothing selected. And while you may understand that, there are many inexperienced users of Geany.

Not really: Geany's custom keybinding handling will not consider the menu sensitiveness, and all handlers are guarded appropriately. And well, in this case it's not guarded, but it's not useful: copy/cut just doesn't do anything when there's no selection.
Currently items sensitiveness is just a display thing. Important for the UI POV, but not for the internal logic one.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.