Conemu: Sometimes pressing on arrow keys prints symbols

[lazycoder-ru]

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.