Maximus5 / ConEmu

Customizable Windows terminal with tabs, splits, quake-style, hotkeys and more
https://conemu.github.io/
BSD 3-Clause "New" or "Revised" License
8.61k stars 575 forks source link

Sometimes pressing on arrow keys prints symbols #1691

Open lazycoder-ru opened 6 years ago

lazycoder-ru commented 6 years ago

Versions

ConEmu build: 180626 x64 OS version: Windows 10 x32/x64 Used shell version: bash.exe from WSL(debian)

Problem description

Sometimes arrow keys(and PgUp, PgDn) do not move the cursur, but prints symbols. It appears only with ConEmu, but when I run bash.exe directly from Windows I have no problems.

Steps to reproduce

  1. Open ConEmu;
  2. Run task Bash(from linux subsystem);
  3. ssh to remote server;
  4. open text editor and move cursor by arrow keys;

Actual results

Arrow keys sometimes prints symbols(A,B,C,D).

Expected results

Arrow keys just moving cursor in editor.

Additional files

conemu_error

cspotcode commented 6 years ago

I believe that these issues are caused by the way ConEmu sends bytes to the target executable's stdin. When the ANSI sequences get split up over multiple read() calls, the target program doesn't necessarily wait for the full ANSI sequence to arrive, so the target program interprets the left arrow key as its constituent parts: "Escape", "[", "C".

I informally tested this by writing a simple C program that calls read() in a loop and logs the results. So as you hit keyboard keys, it logs the bytes of each keystroke, one read() call per line.

When running bash without ConEmu, keystrokes are never split up across multiple read calls. But within ConEmu, they are occasionally split up.

Here's the code. You can save as main.c, compile with gcc main.c, and then run it: stty -icanon -echo ; ./a.out Hold down a key and watch the program read them from stdin. Try it in bash and then again in bash within ConEmu. (stty is required to turn off the tty's echo and canonical modes. Note this will suppress character output after you Ctrl+C out of the program; this is not a bug; stty echo to turn it back on)

#include <unistd.h>
#include <stdio.h>

int main(int argc, char** argv) {
    char buffer[100];
    while(1) {
        ssize_t count = read(0, buffer, 100);
        for(int i = 0; i < count; i++) {
            printf("%#02x ", buffer[i]);
        }
        printf("\n");
    }
}

My workaround for this problem is an expect script that uses interact mode with a regexp that matches ANSI key sequences. It effectively buffers them and sends them to the target executable all at once, so that ANSI sequences don't get split.

Maximus5 commented 5 years ago

Do you run bash (wsl) via connector?

gussmith23 commented 5 years ago

I am also encountering this issue. It's really frustrating -- it makes parts of Emacs unusable! Let me know if I can do anything to help.

gussmith23 commented 5 years ago

The task I'm getting this issue on:

set "PATH=%ConEmuBaseDirShort%\wsl;%PATH%" & %ConEmuBaseDirShort%\conemu-cyg-64.exe --wsl -C~ -cur_console:pm:/mnt -t zsh
gussmith23 commented 5 years ago

Another interesting pattern I've noticed: I can't get this to happen when I start up the task and push arrow keys on a fresh terminal. But if I open emacs on the terminal, and then push arrow keys, it begins to happen.

gussmith23 commented 5 years ago

@cspotcode can you link your workaround script? I can try to reimplement, but if you could give me the gist of it that would be super useful.

cspotcode commented 5 years ago

@gussmith23 sorry I don't think I have it on-hand anymore.

tonglianheng commented 5 years ago

@Maximus5 I have encountered the same issue with version 190714. I am using WSL with wsl-bridge as recommended in the doc. Repeated press of arrow keys would insert random A, B, C and D.

I did some experiments and found something interesting, which may be helpful:

This error seems to only occur when the AppKeys mode is switched on. After I have disabled AppKeys from terminal modes while I am in emacs, everything then works as intended. Arrows still work, and no random insertions would occur. As soon as I switched on AppKeys, the bug would appear. It seems that the escape seuqnces like ^[[A are always read as a whole, while ^[OA are not.

I did try to turn off AppKeys from start up, by setting the task option:

-cur_console:p3m:/mnt

This did initially set the terminal mode to XBC, however as soon as I start emacs, the mode goes back to XABC. Is this because wsl-bridge receiving emacs's request to turn on this mode?

Currently I can manually switch the AppKey mode off each time. But I hope this could be fixed soon, as it does quite seriously impact productivity, especially in emacs. Before I found this "fix" of turning off AppKey mode, I had many incidents of unintended insertions of random characters into my code, which is a pain. I also had to turn off mouse scrolling, as it just inserts those characters like crazy.

tonglianheng commented 5 years ago

Another interesting pattern I've noticed: I can't get this to happen when I start up the task and push arrow keys on a fresh terminal. But if I open emacs on the terminal, and then push arrow keys, it begins to happen.

This is because in bash AppKeys mode is turned off. It switches on automatically when emacs opens.

This does not appear to be a problem if you start WSL directly as a task without wsl-bridge---though you will have many other issues---. I think this may be because without wsl-bridge, conemu will not be able to receive request from apps to turn on AppKeys.

tonglianheng commented 5 years ago

Just as a thought, this could be an issue with cygwin-connector rather than ConEmu. But this issue is currently really annoying, probably the biggest issue with ConEmu for me at the moment. I have to remember to manually switch off AppKeys mode everytime apps like emacs starts, or random characters gets inserted. and breaks many emacs modes where I have to use arrow keys. I have already disabled all mouse support too.

I really hope this issue gets fixed soon.

lpulley commented 4 years ago

I'm having this issue with GHCi for Haskell, but not in vim or on the shell. I don't use emacs. I use WSL on ConEmu version 191012 preview via Cmder. Has there been any progress on this? It inserts characters more often than not and it's making interactive Haskell work impossible.

mjarosie commented 4 years ago

Having the same issue while using stack repl:

ConEmu_appearing_characters_issue

daxgames commented 4 years ago

I have this is issue using vim from Git for Windows in a Cmd.exe session using Cmder.

B from holding the down arrow. A from holding the up arrow. C from holding the right arrow. D from holding the left arrow.

daxgames commented 4 years ago

Some more info setting TERM=xterm-256 solve this issue in Cmder but causes many others so it is not an acceptable fix.

This is only using arrow keys. Using h, j, k, l in vim does not have this issue.

daxgames commented 4 years ago

Using ConEmuBuild=200713 with default Conemu settings arrow keys do not work at all using Git for Windows 2.28.0 vim.exe from CMD.exe.

Setting TERM=cygwin enables arrow keys in vim on CMD.exe but the ABCD issue occurs.

Exact same behavior in Powershell.

Git bash using:

C:\Users\dtgam\cmder\vendor\git-for-windows\git-cmd.exe --no-cd --command=%ConEmuBaseDirShort%\conemu-msys2-64.exe /usr/bin/bash.exe -l -i -new_console:p

Arrow keys work without ABCD issue.

daxgames commented 4 years ago

Behavior in Cmder and Conemu is identical.

daxgames commented 3 years ago

Any word on this? I just tried the latest alpha ConEmuPack.201124.7z and this issue still exists.

Maximus5 commented 3 years ago

https://conemu.github.io/blog/2021/01/09/Build-210109.html

daxgames commented 3 years ago

Thanks @Maximus5,

Testing the release you mentioned above, still happening:

Test 1:

Open a file in vim Line 148 is inserted while holding down the down arrow key:

image

set term in vi returns term-cygwin as set by Cmder.

Test 2:

Opening the same file in a ConEmu Shells::Cmd session does not have the random character issue but the terminal is less performant, it hesitates repeatedly and seems slow while holding down arrow keys. It also occasionally displays the below in the vim status bar:

image

Issuing :set term=cygwin makes the terminal perform better and hesitation while holding arrow keys is gone but the random characters comes back.

Please let me know if I can provide any more details.

Thanks again for the response and your work.

Maximus5 commented 3 years ago

Have you tried official ConEmu, not cmder? I don't know what scripts are set over default config of ConEmu in cmder, is there proper connector loaded, modes were set, and so on.

Maximus5 commented 3 years ago

But... probably this could be fixed by patch proposed in gh-2243

daxgames commented 3 years ago

The second test was Conemu running Shells::cmd default session from conemu with no Cmder init scripts. I edited my previous report to make that more clear.

daxgames commented 3 years ago

@Maximus5 I don't know what you mean by 'is there proper connector loaded, modes were set, and so on'. Tests are conducted with Cmder and ConEmu cmd.exe sessions.

I looked at the patch you mentioned. There is definitely intermittent yet very frequent lag using arrow keys when vim term=xterm-256.

That lag goes away when term=cygwin is set but holding down arrow keys now insert random characters intermittently. I guess the Cmder developers figured this out and started using term=cygwin to fix this lag before I became involved with the project.

I can tell you the arrow key lag and random character thing did not happen in cmd.exe sessions using vim from Git for Windows 2.29.1 with Conemu 16.12.06 if term=cygwin. Arrow keys do not work at all if term=xterm-256 with the same versions.

Maximus5 commented 3 years ago

What full command is of the Task you running? And please show the screenshot of ConEmu with status bar visible.

daxgames commented 3 years ago

@Maximus5 Thanks for your patience.

image

On the left is the ConEmu Cmd.exe Task shells::cmd on the right is ConEmu Cmd.exe Taskcmd::Cmder

Test 1 above was done in cmd::Cmder.

  1. no arrow key lag
  2. Random characters when holding arrow keys.

Test 2 above was done in shells::cmd.

So I am only seeing random characters holding arrow keys when term=cygwinwhether in Conemu Cmd.exe or Conemu Cmd.exe inited with Cmder's init.bat. I am thinking that the term type + the code in the previously mentioned patch do not get along.

daxgames commented 3 years ago

@Maximus5 I have been reading your https://conemu.github.io/en/CygwinMsys.html to try and understand better.

I just tested Windows cmd.exe running the same vim.exe from Git for Windows with term =cygwin set in vim outside Conemu.

Just an FYI.

daxgames commented 3 years ago

Just tried Conemu 210112 same issues as reported in all situations before

daxgames commented 3 years ago

Just tried 210206 same issues as reported in all situations before.

daxgames commented 3 years ago

Just tried Conemu 210304 same issues as reported in all situations before.

tomdowbelkin commented 3 years ago

I've been seeing this also in CMD from the last few Preview builds, currently running 210314. When I run certain commands, such as ll or history, hitting up or down winds up printing [A or [B. Sometimes I have to hit up several times for it to get to the actual history, etc. I've tried tweaking several settings, including ANSI-handling, tried different vals for TERM, but it still occurs.

Running the last version of Cmder, updating ConEmu to latest I don't see it but then I can't run the same commands, so perhaps it is particular to something in Cmder.

https://user-images.githubusercontent.com/4642677/111711299-9a9c9100-8808-11eb-9218-15034bdd8887.mp4

MaximilianEmel commented 3 years ago

I've been seeing this also in CMD from the last few Preview builds, currently running 210314. When I run certain commands, such as ll or history, hitting up or down winds up printing [A or [B. Sometimes I have to hit up several times for it to get to the actual history, etc. I've tried tweaking several settings, including ANSI-handling, tried different vals for TERM, but it still occurs.

Running the last version of Cmder, updating ConEmu to latest I don't see it but then I can't run the same commands, so perhaps it is particular to something in Cmder.

Cmder.2021-03-18.16-33-02.mp4

I have this exact same issue.

cspotcode commented 3 years ago

I'm wondering if this is the culprit:

https://github.com/Maximus5/ConEmu/commit/e6d609925f5708fac687b5f3c638d5b628154ede#diff-0536ea8ff3f0a2b64eba463f2a56d41decc2cc99a3185dabec1324c8e94e3961R226

ANSI escape sequences are being grouped up so that they're buffered on the receiving end, but if there's a momentary hiccup in communication in the middle of sending one of these sequences, then this logic appears to bail out.

Can the timer can be implemented on the transmitting end instead of the receiving end? Or is it even necessary? If the transmitting end is talking directly to the keyboard, then it knows what key was pressed, so there is no ambiguity. The transmitting end knows whether to send a lone escape byte or to send a full ANSI escape sequence. Then the receiving end can safely wait for a full sequence, knowing the sender will signal when it is finished.

daxgames commented 3 years ago

Just tried Conemu 210912 same issues as reported in all situations before.

daxgames commented 2 years ago

@Chrisant996 I hate to ask you to look into this because I don't think it is a Clink issue but I think you have the skills and knowledge to help get this long standing issue fixed. It is incredibly annoying and I just want it fixed. :-)

See my above posts starting here https://github.com/Maximus5/ConEmu/issues/1691#issuecomment-674447078

I can make this error go away in Conemu resulting in poor performance in the form of cursor movement lag when using arrow keys. See: https://github.com/Maximus5/ConEmu/issues/1691#issuecomment-759061205 For 'Test 2' no clink was loaded using Conemu with a cmd.exe shell that is part of Conemu's default tasks so this tells me clink is not the issue.

@Maximus5 Is it possible to use the connector with shells other than bash.exe. I have tried with cmd.exe but been unsuccessful.

daxgames commented 2 years ago

@Maximus5 @chrisant996 I just retested vim in Cmder cmd.exe shell using term=xterm-256color and to my surprise it seemed fine with a VERY limited test. There was no cursor lag like there was before and no random ABCD characters. This is a good sign.

I am going to play with it more and will comment back here.

chrisant996 commented 2 years ago

@daxgames I would have anticipated this would be #2302, and would be fixed in ConEmu 210422.

On Sep 17, 2021 you said 210912 still exhibits the problem in all cases. And today you said with term=xterm-256color it seems to work.

Does that mean that the %term% value changes how it behaves? I.e. does it work with xterm-256color, but not with other %term% values?

Or does it mean that something seems to have changed between Sep 17 2021 and now?

daxgames commented 2 years ago

Cmder cmd.exe Conemu tasks set by default set term=cygwin. I am not sure why as this setting pre-dates my involvement with the project. The random ABCD problem appeared in a Conemu pre release sometime in 2020 I think with this setting.

In my earlier testing setting term=xterm-256color resolved the ABCD issue but introduced severed cursorredraw latency when moving with arrow keys.

Today I asked you to look without first trying term=xterm-256color to see if the latency issue was gone.

I went back and reread some of my posts and decided to try the term=xterm-256color setting again. To my surprise all seems good now but I did a very limited test.

I want to work with it set this way for an extended period of time before I call this fixed because I remember other issues were introduced by using this setting I just can't remmer what they were.

chrisant996 commented 2 years ago

Ahh, I get it. That's interesting. Seems like the term setting indeed influences the Terminal Mode handling in ConEmu.

Hopefully all goes well during the test period, but if not then I probably can dig in a little to help identify options for next steps.

doctorpangloss commented 2 years ago

I am still experiencing this issue using busybox64.exe and ConEmu 220807.

vctls commented 1 year ago

Was facing this issue as well. Not sure when and why it started. Removed everything, reinstalled, gone.

nmz787-intel commented 1 year ago

with ConEmuPack.220807.7z on Windows 11 I get this bug with just the standard cmd.exe shell.

Fix seems to be:

image

works for command history when pressing up/down, instead of printing ^[OA etc... not sure yet if it will break other programs that I open from the cmd-prompt!

nmz787-intel commented 1 year ago

update, after running a git push I'm back to seeing codes, :(

nmz787-intel commented 1 year ago

annnnd, running clear now makes history work again. What's going on here???

chrisant996 commented 1 year ago

Sounds similar to https://github.com/Maximus5/ConEmu/issues/2302. See here for how to check whether the ConEmu terminal mode is being slow to change back to "WK".

(It's unlikely to be related to the "ANSI and xterm sequences" setting or the commands that were run; it was probably coincidence that changing it appeared to have an effect on this. The issue has to do with the ConEmu terminal mode; see links above.)

grable0 commented 1 year ago

I get this in version 23074 too in standard cmd.exe tasks, i just recently upgraded from a very old version (180xx something) and never noticed this before. Calling any executable, even windows standard ones like find and pressing UP arrow before it exits or right after it exits and an [A will be printed on the command line.

EDIT: seems @chrisant996 is right, after enabling the statur bar, i can see that ConEmu is indeed changing to XK and then taking 5 seconds or so to change back to WK. This happens even with xterm/ansi disabled, so i dont know why it enables it for even bog standard windows executables.

grable0 commented 1 year ago

I found a comment by @pyhedgehog in issue #2302 about using gui macro TermMode(0,0) but that didnt work, then i saw another ANSI macro doing this directly, $E]9;10;0$E\ which when added to the prompt string immediately disables XK mode every time the prompt is printed.

chrisant996 commented 1 year ago

I get this in version 23074 too in standard cmd.exe tasks, i just recently upgraded from a very old version (180xx something) and never noticed this before. Calling any executable, even windows standard ones like find and pressing UP arrow before it exits or right after it exits and an [A will be printed on the command line.

EDIT: seems @chrisant996 is right, after enabling the statur bar, i can see that ConEmu is indeed changing to XK and then taking 5 seconds or so to change back to WK. This happens even with xterm/ansi disabled, so i dont know why it enables it for even bog standard windows executables.

@grable0 I just downloaded ConEmu 230724 and tried to reproduce what you've described. But for me the terminal mode immediately resets (or doesn't even change), no matter what executable I run. I tried some cygwin executables, some console mode and GUI executables that are part of Windows, and some third party console mode and GUI executables.

Check out ConEmu | Terminal input and output modes. It says that if the ENABLE_VIRTUAL_TERMINAL_INPUT console mode is set in the console, then ConEmu will use XTerm terminal input mode.

So, I bet one of the programs you use is setting the ENABLE_VIRTUAL_TERMINAL_INPUT mode, but neglects to revert it back to normal when finished, thus polluting the console and affecting all subsequent programs and input in that console window.

grable0 commented 1 year ago

@chrisant996 thank you for looking into this again :D

After digging some more these are the modes set by default in fresh terminals

input mode:
        ENABLE_ECHO_INPUT
        ENABLE_INSERT_MODE
        ENABLE_LINE_INPUT
        ENABLE_PROCESSED_INPUT
output mode:
        ENABLE_PROCESSED_OUTPUT
        ENABLE_WRAP_AT_EOL_OUTPUT
        ENABLE_VIRTUAL_TERMINAL_PROCESSING

And they stay that way even after running several programs. But this did force me to double check that Clink wasnt the issue, and wouldn't you know, when i disabled Clink i could not reproduce it! So it appears that Clink v1.5.4.6f56dd was the culprit :( The modes still stay the same with out without Clink though, so there must be something it does that ConEmu detects and enables XK.

So for now il have to continue using that ANSI sequence to disable XK in the prompt. which is a nice workaround for me since i really really like using Clink.

chrisant996 commented 1 year ago

But this did force me to double check that Clink wasnt the issue, and wouldn't you know, when i disabled Clink i could not reproduce it! So it appears that Clink v1.5.4.6f56dd was the culprit :( The modes still stay the same with out without Clink though, so there must be something it does that ConEmu detects and enables XK.

@grable0 This is very strange.

I can't reproduce the problem using Cmder 1.3.21 or ConEmu 230724 with Clink v1.5.4, so I need your help to identify what's special about your computer.

(P.S. If you turn on the ConEmu StatusBar, right-click it, and choose "RealConsole modes" then ConEmu shows the current input and output console mode flag bits in the StatusBar. Very convenient!)

chrisant996 commented 1 year ago

@grable0 Two things:

  1. Can you run clink set debug.log_terminal true, start a new cmd/clink task in ConEmu, reproduce the problem, and then share your clink.log file? (Run clink info to find the log file.)
  2. Would you be willing to share the script(s) that implement your custom prompt?

I've spent a while reviewing the ConEmu source code. It looks like there are several ways to manually force XTerm mode, there are escape codes to force it, the Connector forces it, and the ENABLE_VIRTUAL_TERMINAL_INPUT flag forces it.

Clink doesn't do or trigger any of those. But, Clink does run prompt scripts, and there have been several times where strange problems eventually got tracked down to prompt themes or prompt scripts containing unexpected stray escape codes that force various things that shouldn't be forced.

So, I would like to examine what the prompt string contains, to rule out script issues as a possible cause.