Sometimes pressing on arrow keys prints symbols

[lazycoder-ru]

trafficstars

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

[cspotcode]

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]

Do you run bash (wsl) via connector?

[gussmith23]

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]

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]

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]

@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]

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

[tonglianheng]

@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]

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]

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]

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]

Having the same issue while using stack repl:

[daxgames]

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]

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]

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]

Behavior in Cmder and Conemu is identical.

[daxgames]

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

[Maximus5]

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

[daxgames]

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:

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:

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]

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]

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

[daxgames]

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]

@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]

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

[daxgames]

@Maximus5 Thanks for your patience.

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.

• shell config: term=cygwin
• vim config: term=cygwin

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

Test 2 above was done in shells::cmd.

• shell config: term is unset

• vim config: term=xterm-256

  1. Has significant arrow key lag.
  2. No Random characters when holding arrow keys.

• Open a file in vim

  1. :set term=cygwin
  2. No arrow key lag
  3. Random characters when holding arrow keys.

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]

@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.

• No arrow key lag
• No random characters when holding arrow keys.

Just an FYI.

[daxgames]

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

[daxgames]

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

[daxgames]

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

[tomdowbelkin]

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