GeanyLua has an X11 dependency

[elextr]

Geany Lua depends on getting X11 events here. This means it won't work on Windows, Macos or Wayland AFAICT.

[Edit: on closer inspection there is a #else clause for Windows, so its handled]

Should be using the "official" plugin keybinding interface instead, making it portable.

[xiota]

Are you able to tell whether this is for "The old way" described here? If so, I think it can be removed, since it's already been deprecated.

[elextr]

No, on looking closer its nothing to do with keybindings (AFAICT) its the implementation of keygrab().

That should be implemented by adding a signal handler for keystrokes before Geanys on the normal GTK keystroke signals "key-press-event" and "key-release-event" (IIRC). That will still allow it to block keystrokes from Geany (bad form, but possibly necessary) but not have to dive to the low level of event filters on widgets and will deliver a portable GdkEventKey, not the non-portable underlying OS structure that needs X11 or (in the #else) windows.h and doesn't handle Wayland.

[elextr]

Hint: have a look at Geany's keybindings.c and how it collects keystrokes. IIRC there is a GTK function to connect_before on an event, so that callback would grab the key before Geany (if it returned TRUE, FALSE passes the key to the next connection).

[xiota]

I took a look at the code. Problem is I don't know how to...

• Suspend Lua execution while waiting for a result from the callback.
• Return a result from the callback or resume Lua execution from the callback.

What are the use cases for geany.keygrab? None of the example scripts use it, and geany.input seems suitable for most user input. geany.keygrab documentation says:

This function was primarily intended for assigning "chained" sets of hot key options, in conjunction with user-defined keybindings.

So the creation of multi-key/step shortcuts? Is that really useful?

[elextr]

Suspend Lua execution while waiting for a result from the callback.

It doesn't suspend, keygrab() just sleep loops here and seems to use the global variable km to communicate between the callback from the widget filter (X11 or Windows version of) keygrab_cb().

What I'm suggesting is that it be rewritten to not use window filters but to replace this with a call to g_signal_connect similar to keybindings.c in Geany itself.

It will require rewriting the signal handler since the returned event data is different to either existing one, but its the same for all platforms so its portable. Also Glib/GTK does the keymap crap before it returns the event, so all that can be deleted, yay less code.

Since it seems to work for those who use it, the sleep loop approach can probably be kept no matter how smelly it is 👃

What are the use cases for geany.keygrab?

Just because neither you nor I am smart enough to figure a use-case immediately doesn't mean someone else hasn't, the function has been there for a long time (at least since 2009 when the plugin was moved to geany-plugins), so no it can't be removed.

[xiota]

geany.keygrab() hangs on X11. Using KDE Plasma 5.27.2. Geany 1.38. Geany Plugins 1.38. GTK 3.24.37. GLib 2.74.6. Built and tested with both Lua 5.1 and LuaJIT with same result.

Looks like the callback function either doesn't return or doesn't set the flag to signal that a key has been pressed so that the wait loop can exit. The relevant code is the same in 1.38 and the current git revision.

Example Lua code:

geany.status("keygrab - start")
key = geany.keygrab()
geany.status(key)
geany.status("keygrab - end")

Status window shows only:

keygrab - start

Keyboard input continues to be sent to the editor. Geany has to be force closed.