Open lazycoder-ru opened 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.
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.
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
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.
@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.
@gussmith23 sorry I don't think I have it on-hand anymore.
@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.
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.
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.
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.
Having the same issue while using stack repl
:
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.
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.
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.
Behavior in Cmder and Conemu is identical.
Any word on this? I just tried the latest alpha ConEmuPack.201124.7z and this issue still exists.
Thanks @Maximus5,
Testing the release you mentioned above, still happening:
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.
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.
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.
But... probably this could be fixed by patch proposed in gh-2243
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.
@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.
What full command is of the Task you running? And please show the screenshot of ConEmu with status bar visible.
@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
.
term=cygwin
term=cygwin
Test 2 above was done in shells::cmd
.
shell config: term is unset
vim config: term=xterm-256
Open a file in vim
:set term=cygwin
So I am only seeing random characters holding arrow keys when term=cygwin
whether 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.
@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.
Just tried Conemu 210112 same issues as reported in all situations before
Just tried 210206 same issues as reported in all situations before.
Just tried Conemu 210304 same issues as reported in all situations before.
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
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.
I'm wondering if this is the culprit:
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.
Just tried Conemu 210912 same issues as reported in all situations before.
@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.
@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.
@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?
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.
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.
I am still experiencing this issue using busybox64.exe and ConEmu 220807.
Was facing this issue as well. Not sure when and why it started. Removed everything, reinstalled, gone.
with ConEmuPack.220807.7z
on Windows 11
I get this bug with just the standard cmd.exe
shell.
Fix seems to be:
ConEmu
window
Settings
Integration
-> ANSI execution
ANSI and xterm sequences
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!
update, after running a git push
I'm back to seeing codes, :(
annnnd, running clear
now makes history work again. What's going on here???
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.)
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.
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.
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 likefind
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 toWK
. 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.
@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
.
But this did force me to double check that
Clink
wasnt the issue, and wouldn't you know, when i disabledClink
i could not reproduce it! So it appears thatClink v1.5.4.6f56dd
was the culprit :( The modes still stay the same with out withoutClink
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.
clink autorun uninstall
) and then create a new ConEmu task and run clink inject
?(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!)
@grable0 Two things:
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.)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.
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
Actual results
Arrow keys sometimes prints symbols(A,B,C,D).
Expected results
Arrow keys just moving cursor in editor.
Additional files