wordgrinder-0.8.1 ESC Key seems slow?

[rogerxxxx]

I'm using wordgrinder-0.8.1 prebuilt package on Void Linux, and word grinder response seems slow?

Pressing ESC for menus, wordgrinder delays for 1-3 seconds before opening the menus.

Typing text seems OK, or at normal speed rates, as well as navigating the menus with the cursor keys.

I'm thinking this has to do with the programming purposely delaying ESC key presses for some odd reason?

[rogerxxxx]

I've worked around the ESC menu being slow, by (likely more properly) binding F1, F2, F3, F4, F5 keys to eache of the File, Edit, Style, Documents, Navigation main menu items.

However, pressing accelerator (F1, F2, ...) key for each menu item will pop-up the menu item, but each menu item appears to persist permanently until the ctrl-c keys are pressed. This also extremely odd and significantly impedes workflow! I also suggest here, making the menu disappear on each and every other press of the accelator (F1, F2, ...) key press.

In other words, those of us following our laws for typing, we keep our fingers on the keyboard versus dancing around pressing other buttons. I think most other command line utility menus operating similarly, first click of the mouse or key activates a menu item, while each subsequent or every other press deactivates/clears the menu, rather than lifting our fingers and pressing a key from the opposite side of the keyboard.

There also seems to be a few significant updates to the source code repository since the last release many years ago, I probably should compile and test from the repository instead, before filing more bugs!

Seems the slow ESC key bug is ncurses related. And if wordgrinder already pre-defined the menu items with function keys, would be readily worked around, however then users could not remap the menu items to other more readily pressed keys, depending on disability.

[davidgiven]

This is normal --- it's an ncurses thing. Technically, it's because when ncurses sees an ESC character it can't tell whether the user has actually pressed ESC or whether it's the first character of a multicharacter sequence. So it pauses for (by default) 500ms to see whether any more characters are coming.

What I do is use ALT+letter to open the top level menus. (Using the ALT modifier sends the letter with a leading ESC.)

Regarding the function keys: do you mean that you're using the accelerator keys while the menu is open? That's supposed not to work. When in menu mode, accelerators aren't processed because they don't make sense there. e.g. UP ARROW is normally bound to Cursor Up (in the Navigation menu), which moves the cursor in the document, but when a menu is open you don't want that to happen. Also, allowing menu keys to be rebound can potentially cause the user to be completely locked out of the UI.

[rogerxxxx]

Might be nice to add the ncurses ESC delay waiting for additional key press (char) input to the readme, now I completely understand why the delay cannot be worked around. On second thought, maybe proposing a patch for ncurses, an option when using ESC key to turn-off the ESC multi-character or multiple key press function.

I'm just tagging the File menu as F1, ... and so one with Edit F2, Style F3, ... menus, so the sub-menus open as soon as I press the respective function keys.

Would be nice to already pre-define the sub-menus with F1, F2, F3, ... but only temporarily defined so users can choose other keys. This would certainly workaround, for now, the ESC key delay. Many users, including me, expect things to just work at the press of a key with no delays. Encountering delays drives people nuts, unless they're on drugs. And, most do not spend time reading source code, or source code readmes.

In other words, include an example .wordgrinder/startup.lua file for distribution package builders, and include the following:

-- Provide user Function keys for common sub-menus
-- This also worksaround ncurses' ESC key's multi-character delay
OverrideKey("F1", "F")
OverrideKey("F2", "E")
OverrideKey("F3", "S")
OverrideKey("F4", "D")
OverrideKey("F5", "Z")

Currently, at least within 0.8.1 version on Void Linux here, the wordgrinder package includes no example configuration file. If there's no example configuration file, users are less apt to use one or at least learn the configuration file.

Now, I think just the keys need to toggle the sub-menus, rather than stick permanently open until ESC key is closed again. In other words, press F1 key for File sub-menu, press F1 key again for closing (toggling) the sub-menu. Otherwise depending upon the ESC key again inhibits the horrid multi-character ESC delay again!