You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue has been mentioned before, but with no real solution (#1994, #2274).
Description of the problem or steps to reproduce
The ESC key seems to be ignored on Windows, but shows OK at the "raw" tab.
Steps:
Press Ctrl-e for command mode.
Press ESC
Expected result: The command pane closes
Actual result: nothing happens
If typing Ctrl-e and then raw and enter, and then pressing ESC, each press shows as:
EventKey: Esc: ""
Specifications
Version: 2.0.12
Commit hash: c2cebaa
Compiled on September 06, 2023
Also happens on any pre-built 2.0 version (first pre-built binary is 2.0.0-rc3).
Doesn't happen on the 1.4.1 pre-built binary. I.e. ESC is recognized and the command pane is closed, selection gets deselected, etc.
OS: Windows 10, Windows 7.
Terminal:
Windows 10: native console and Windows terminal (several versions, up to current latest - 1.19).
Windows 7: native console.
Analysis:
The issue appears to be a regression of commit 37a4cbf, by this part of the diff:
diff --git a/cmd/micro/action/bindings.go b/cmd/micro/action/bindings.go
index 3ed86dc0..2b5173a3 100644
--- a/cmd/micro/action/bindings.go+++ b/cmd/micro/action/bindings.go@@ -99,30 +99,32 @@ modSearch:
// marked escape sequences for control keys
// We should check for Control keys first
if modifiers&tcell.ModCtrl != 0 {
// see if the key is in bindingKeys with the Ctrl prefix.
k = string(unicode.ToUpper(rune(k[0]))) + k[1:]
if code, ok := keyEvents["Ctrl"+k]; ok {
var r tcell.Key
- if code < 256 {+ // Special case for escape, for some reason tcell doesn't send it with the esc character+ if code < 256 && code != 27 {
r = code
}
// It is, we're done.
return KeyEvent{
code: code,
mod: modifiers,
r: rune(r),
}, true
}
}
// See if we can find the key in bindingKeys
if code, ok := keyEvents[k]; ok {
var r tcell.Key
- if code < 256 {+ // Special case for escape, for some reason tcell doesn't send it with the esc character+ if code < 256 && code != 27 {
r = code
}
return KeyEvent{
code: code,
mod: modifiers,
r: rune(r),
}, true
And indeed, removing the code != 27 part of the conditions makes ESC great again on Windows too (I'm guessing only the 2nd condition matters, because Ctrl-ESC is intercepted by the system on Windows. Not sure though).
This "fix" works on both windows 7 and 10, both windows terminal and native console, and makes ESC close the command pane, deselect, abort an action which asks (y,n,esc), etc - all of which don't work in the current version on Windows.
I don't know if that's a correct fix, but it does seem to suggest that the comment is incorrect on Windows.
The text was updated successfully, but these errors were encountered:
avih
changed the title
Windows: ESC only works in "raw" tab (regression, patch inside)
Windows: ESC key only works in "raw" tab (regression, patch inside)
Oct 4, 2023
I'm experiencing the same behavior of the escape not working, but Micro catching it in raw.
Windows 10 Enterprise, Powershell 7.4, Micro 2.0.12 (commit hash c2cebaa3)
This issue has been mentioned before, but with no real solution (#1994, #2274).
Description of the problem or steps to reproduce
The ESC key seems to be ignored on Windows, but shows OK at the "raw" tab.
Steps:
Press
Ctrl-e
for command mode.Press ESC
Expected result: The command pane closes
Actual result: nothing happens
If typing
Ctrl-e
and thenraw
and enter, and then pressing ESC, each press shows as:Specifications
Version: 2.0.12
Commit hash: c2cebaa
Compiled on September 06, 2023
Also happens on any pre-built 2.0 version (first pre-built binary is 2.0.0-rc3).
Doesn't happen on the 1.4.1 pre-built binary. I.e. ESC is recognized and the command pane is closed, selection gets deselected, etc.
OS: Windows 10, Windows 7.
Terminal:
Windows 10: native console and Windows terminal (several versions, up to current latest - 1.19).
Windows 7: native console.
Analysis:
The issue appears to be a regression of commit 37a4cbf, by this part of the diff:
And indeed, removing the
code != 27
part of the conditions makes ESC great again on Windows too (I'm guessing only the 2nd condition matters, because Ctrl-ESC is intercepted by the system on Windows. Not sure though).This "fix" works on both windows 7 and 10, both windows terminal and native console, and makes ESC close the command pane, deselect, abort an action which asks
(y,n,esc)
, etc - all of which don't work in the current version on Windows.I don't know if that's a correct fix, but it does seem to suggest that the comment is incorrect on Windows.
The text was updated successfully, but these errors were encountered: