Hi Lex,
Doesn't matter what you do, any handler returning TRUE will stop other handlers being called within signal_emit before it returns to you. https://developer.gnome.org/gtk3/stable/GtkWidget.html#GtkWidget-key-press-e...
This is true, for 'key-press-event' and 'key-release-event' at least. However, for my 'pre-key-press-event', it is NOT the case; all connected callbacks are always called. I'm guessing that GTK makes a distinction between events originating in X or the kernel, and user-created events, or maybe just event generated by g_signal_emit_by_name calls.
The upshot of all this is:
1. Can't use key-press-event, because Geany filters out all key strokes bound by any installed plugin. 2. Can't use key-release-event, because at least two other plugins use it, and filter out the event in some circumstances. 3. My proposed pre-key-release-event signal is unfilterable, and so is suitable for plugins that need a 'look but don't touch' event. However, it would still not stop a plugin determined to usurp a key bound to someone else. Despite that, I still think it's worth implementing.
This has been an interesting learning experience for me, so my thanks to you and to Matthew for all the discussion.
Cheers, Austin.