search

cmderdev / cmder

Lovely console emulator package for Windows
https://cmder.app
MIT License
26k stars 2.03k forks source link

[Bug] Control Key gets stuck. #2832

Open jsmunroe opened 1 year ago

jsmunroe commented 1 year ago

Description of the issue

The control key appears to get stuck as pressed. At some point while using Cmder, when I backspace it erases whole words and when I hit up or down to scroll through command history, it changes the existing line to "[A" for up and "[B" for down. Left and right are "[D" and "[C" respectively. I have to restart it when this happens.

It has been happening rather frequently ever since the last update.

After hitting Up key image

How to reproduce

It happens after a random amount of time. I do not know what action triggers it.

Additional context

Full disclosure, I am not certain that this isn't ConEmu, Clink, or other third-party tools that Cmder uses. I'm not sure how I would be certain of that or why that is relevant. If someone had a problem with one of my projects that was a bug with something it was using, that is still a bug in my project. I would want it fixed even if it wasn't directly a problem with my project. But reports help you out too.

I did search for existing problems within the ConEmu space and didn't find anything. I don't see any like issues in the ComEmu GitHub repo.

DRSDavidSoft commented 1 year ago

Thank you for reporting this bug.

Can you please use the unmodified ConEmu for some amount of time to see if this issue can be reproduced with only ConEmu?

Additionally, please use Cmd.exe shell instead of clink if you can, to see if this issue is related to ConEmu or not.

chrisant996 commented 1 year ago

It sounds like the ConEmu terminal mode may be getting stuck in "XTerm" mode.

In the XTerm mode, arrow keys and other special keys get inserted in exactly the way you describe.

ConEmu tries to automatically figure out when to use Windows vs XTerm mode. See ConEmu docs Terminal input and output modes for details.

To make ConEmu show the current terminal mode:

  1. Open the ConEmu Settings dialog.
  2. In the tree view on the left, choose "Status bar" under the "Features" heading.
  3. Make sure the "Show status bar" checkbox at the top is checked.
  4. In the "Available columns" list, find and double-click on "Terminal modes" to add it to the status bar.
  5. Click "Save Settings".

Now the status bar will show "W" for the normal Windows mode, and "X" for the XTerm mode. (There may or may not be a "K" or other letter next to it as well.)

jsmunroe commented 1 year ago

It shows Wk in the status bar when the problem exists. Here are the status bars for two windows, the top has the problem, the bottom is a brand new window that does not have the problem.

image

chrisant996 commented 1 year ago

@jsmunroe In any case, this seems like a ConEmu issue, not a Cmder issue.

Or it may be due to a console mode program changing the console mode to activate VT100 emulation at the OS level.

See if you can track down what program is used right before the problem begins to occur.

chrisant996 commented 1 year ago

@jsmunroe Clink v1.5.1 was published a few minutes ago and clears the ENABLE_VIRTUAL_TERMINAL_INPUT mode even more aggressively than before. Some console programs set it but neglect to clear it, and that's what causes the problem you reported.

Also, some console mode programs continue to run and use their parent's terminal input/output handles even after the parent (e.g. cmd.exe) regains control and shows an input prompt. That's especially problematic for two reasons:

  1. They may set ENABLE_VIRTUAL_TERMINAL_INPUT again even after Clink has cleared it multiple times already (especially if a console mode program gets aborted e.g. via Ctrl-C, which can interfere with their ability to restore the console mode if they don't have proper error handling code).
  2. They may read from the terminal or write to the terminal, and if either of those happen it interferes with cmd.exe (either cmd.exe will get the input, or the other program will get the input -- not both -- and the input and output get jumbled in that case).

Clink tries its best to compensate for those other buggy programs/scripts, but there is only so much that Clink can do to defend against them.

Ultimately, you need to track down which programs and/or scripts are triggering the problem, and then get them fixed.

jsmunroe commented 1 year ago

I guess it would have to be git since that's what I use most of the time.

chrisant996 commented 1 year ago

I guess it would have to be git since that's what I use most of the time.

Seems unlikely. I use git all the time and I've only run into this 3 or 4 times in 2.5 years, and it was definitely with other programs not git.

However, it could potentially be an external tool that's been configured to be spawned by git (e.g. a diff tool or merge tool or etc).

chrisant996 commented 1 year ago

... or it's also possible that you're hitting something different that might be purely a ConEmu issue. I don't use ConEmu.

By the way, I'm pretty sure the issue has nothing to do with the Ctrl key getting stuck. It's the ENABLE_VIRTUAL_TERMINAL_INPUT console mode, which is something that can only be changed programmatically. The VT100 escape codes for up, down, right, left are ESC [ A, ESC [ B, ESC [ C, and ESC [ D, respectively.

daxgames commented 1 year ago

That was a long standing bug in comemu that was fixed some time ago and I have not seen it since.

When it was an issue I saw it mostly in vim in a cmd.exe terminal.

DRSDavidSoft commented 6 months ago

I have been trying several scenarios for these past couple of months and can confirm this is not related to the passage of an arbitrary amount of time; additionally it can also happen outside of Cmder and ConEmu. One way I have found to trigger it is to ssh into another host, run certain programs, and then hit Ctrl Break to kill the ssh connection. This will result in the same exact issue.

Currently I don't believe this issue is related to Cmder, it might be relevant to something else. Since it also happens with cmd.exe and conhost.exe (no Clink/ConEmu), I'm investigating to see exactly what is being changed in the terminal that causes this.

chrisant996 commented 6 months ago

@DRSDavidSoft it's caused by what I said in this comment.

Some program is changing the console input mode, and not restoring the original console mode before exiting.

DRSDavidSoft commented 6 months ago

@chrisant996 Yeah I assumed that echoing something to the terminal might trigger this while the ENABLE_VIRTUAL_TERMINAL_INPUT flag is set.

Am I correct to assume according to your comment, just by setting the flag this issue can be repro'ed?

chrisant996 commented 6 months ago

You're seeing echo'd input, not output.

It's more complicated than just the flag being set. But the flag is what allows the problem to occur.

And the flag is present because a program explicitly forced it on because the program wants to receive emulated VT input, but the program neglected to restore the original flags before exiting. So then other things can accidentally receive emulated VT input when they aren't expecting it.

ConEmu has a built-in option for showing terminal modes in its status bar. You can use ConEmu to watch for what program(s) sets the flag but exits without clearing it.

KingLurchi commented 2 months ago

For me this seems to happen only when I use certain git shortcuts, but not for all and never if I use the full command.

Command: git status --short --branch
Shortcut: git st

Command: git pull
Shortcut: git pl

Command: git fetch --all --prune
Shortcut: git fap

Once you enter any other git shortcut that does not trigger this issue, the problem goes away until you use one of the buggy ones again.