Terminal.Gui
Terminal.Gui copied to clipboard
gui-cs
In Curses driver, ESC has a built-in 200ms pause, which makes it hard to make ESC responsive
This is really noticeable in UI Catalog (sync latest to PR) where ESC is used to exit a Scenario.
On Linux (with Curses) it takes 1-2 seconds for the Scenario to close.
I looked at the Unix.MainLoop and Cruses code, but I can't tell why this is.
I have also detected that. I think the cause is this on CursesDriver.
// Special handling for ESC, we want to try to catch ESC+letter to simulate alt-letter as well as Alt-Fkey
if (wch == 27) {
Curses.timeout (200);
Ahhh..
I've confirmed changing my code to look for Key.F1 works around this. So confirmed.
Updated bug description.
@migueldeicaza,
On what systems does alt-letter and alt-fkey not work?
I think it's only very esoteric old stuff, right?
IOW, can we just remove this behavior or make it an opt-in option?
@bdisp asked in #387: "Did you try that removing the timeout in #439 to see if it works without problems?"
Yes, and it removes the delay, but would break the "ESC-F" == "Alt-F" functionality.
Assigning to @migueldeicaza since I think only he can make the call on whether this functionality is still needed in this day and age.
I still rely entirely on ESC-letter on Mac, as generally those keyboard have the F keys needing Fn-Key, which is not easy to hit as ESC-letter :-)
Man, you're old and rigid.
But, I guess you're probably not alone. I didn't realize folks still had those muscle-memories.
I think we're ok leaving this functionality in then. I already established that using ESC as the way to exit an app/screen can be replaced by CTRL-Q so I think we can just adopt that as the standard.
Right?
This should not affect anyone on Windows, there I think we should make ESC immediate, as you typically have working F keys that have not been abused.
For Unix, the idiom is to use "ESC ESC" for a quick response.
This should not affect anyone on Windows, there I think we should make ESC immediate, as you typically have working F keys that have not been abused.
For Unix, the idiom is to use "ESC ESC" for a quick response.
The problem is WSL. Via it, many people use Unix ON Windows.
If you run a Terminal.Gui app under WSL on Windows and you are not familiar with the "ESC as Control key" idiom, it just seems like hitting ESC is slow.
+1 to this, or maybe making it configuration option? It took me significant time to figure out why it took so much time on my Mac, and I really believed whole app was slow (but my app wasn't much more than ESC).
So, if there was a way to set Terminal.GUI to stop waiting for ESC I'd call it quite good workaround, that would work for me 100%.
The problem is that it leaves no option for those that use the terminal remotely, or without F keys (most Mac users do not have the F keys around to be used).
A configuration option would just hide the problem for the tester.
What we could do is perhaps have some heuristics, like for example, if we detect that we are running under WSL, not over SSH, we could make the delay shorter.