Random ←[?1h is showing

[shankiflang]

Describe the bug

When I run any command I get characters like ←[?1h that go everywhere every time I type a character it doesn't know (for example a command that is not in the history)

Screenshots

Desktop

• Windows 10
• Zsh version: 5.8

[0xseven7]

Same to me!

Desktop

• Win10 64bit;
• Zsh version: zsh 5.8 (x86_64-pc-msys)

[kevindqc]

As a workaround, checking out the v0.6.4 tag in my \.oh-my-zsh\custom\plugins\zsh-autosuggestions folder fixes the issue

[sagspot]

Am also facing the same. I don't undustand @kevindqc 's solution. Could you please explain to a newbie ☺️

[zzyy-gh]

Am also facing the same. I don't undustand @kevindqc 's solution. Could you please explain to a newbie ☺️

same

[kevindqc]

You can use this:

cd ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions
git checkout tags/v0.6.4 -b v0.6.4-branch

[sagspot]

Thank you @kevindqc. That fixed my issue.

[ericfreese]

As a workaround, checking out the v0.6.4 tag ... fixes the issue

I don't know what might be causing this, but a big thing that changed between v0.6.4 and v0.7.0 was enabling of async mode by default. Do you see this problem in v0.7.0 with async mode disabled (unset ZSH_AUTOSUGGEST_USE_ASYNC)?

Does the problem occur if you run zsh -df (to not load any custom zsh dotfiles) and source zsh-autosuggestions manually?

When I run any command

Are you saying the characters only appear when you press enter to run the command? Or do the characters appear before you've pressed enter. What exact action makes the characters appear?

[dbachran]

Hi @ericfreese, I tried out switching to HEAD again (instead of 0.6.4) and disabling async mode (via unset ZSH_AUTOSUGGEST_USE_ASYNC). As a result, I am not seeing those funny characters anymore. So this seems to be a viable workaround as well.

[dbachran]

Sorry, missed some parts in your previous question. Let me answer that from my local experience (running zsh-autosuggestions within Cygwin on Windows 10).

Does the problem occur if you run zsh -df (to not load any custom zsh dotfiles) and source zsh-autosuggestions manually?

No, when sourcing zsh-autosuggestions.zsh manually, this seems to work fine, see example below.

When I run any command

Are you saying the characters only appear when you press enter to run the command? Or do the characters appear before you've pressed enter. What exact action makes the characters appear?

For me, those funny characters seem to appear whenever autosuggestions does tread on new commands, i.e. whenever I am typing something for there is no suggestions available, yet.

See the following example, where I started a new "zsh -df" (which was a new command at this time), sourced zsh-autosuggestions manually and tried it out.

/c/Data$ zsh [?1h[?1h[?1h[?1h-[?1h[?1h[?1hd[?1h[?1h[?1hf[?1h[?1h[?1h[?1h
hostname% source ~/.oh-my-zsh/custom/plugins/zsh-autosuggestions/zsh-autosuggestions.plugin.zsh
hostname% echo "this seems to work :-)"
this seems to work :-)
hostname% exit
/c/Data$ echo "this i[?1h[?1h[?1hs[?1h[?1h[?1h[?1h [?1h[?1h[?1h[?1hb[?1h[?1h[?1h[?1hu[?1h[?1h[?1h[?1hg[?1h[?1h[?1hg[?1h[?1h[?1h[?1hy[?1h[?1h[?1h[?1h[?1h"[?1h[?1h[?1h[?1h
this is buggy
/c/Data$ zsh -df
hostname% this was autosuggested, which did not cause any funny characters

[ericfreese]

Thanks for all the info!

No, when sourcing zsh-autosuggestions.zsh manually, this seems to work fine

Ok, this is important. It means that there's something in your local config that is triggering the problem. Can you comment out things from your ~/.zshrc until the problem goes away and then add them back one at a time to see which config from your ~/.zshrc is causing the trouble?

[dbachran]

Well, I guess my ~/.zshrc is not the problem. When stripping off everything except for the following contents, I still get funny characters as soon as I am typing something, where there is no suggestion available, yet.

export ZSH="/home/daniel/.oh-my-zsh"
plugins=(zsh-autosuggestions)
source $ZSH/oh-my-zsh.sh

[dbachran]

I also emptied all contents within ~/.zprofile and ~/.inputrc, without success, unfortunately. Now I got an ugly shell AND funny characters. 😉

[dbachran]

Oh, but I noted the following: I am using a custom console on Windows (https://github.com/cbucher/console), where I am seeing this issue. When trying to reproduce this issue with the Cygwin Terminal (mintty.exe) I do not get those funny characters. So there seems to be something different with regards to how these terminals/consoles behave?

[dbachran]

Please see a cleaned-up diff of running set within each terminal (console vs mintty) below, if this may be of any help?

--- zsh.set.console.sh
+++ zsh.set.mintty.sh
-'$'=1547
+'$'=1481
--=569JNRXZghiklms
+-=569JNRXZghikms
-0=/usr/bin/zsh
+0=zsh
-COLUMNS=140
+COLUMNS=80
+EXECIGNORE='*.dll'
-HISTCMD=3205
+HISTCMD=3204
+HISTCONTROL=ignoredups
+HISTFILESIZE=3000
+HISTIGNORE=$'[ \t]*:&:[fb]g:exit:ls:history:*/dev/clipboard*'
+LC_CTYPE=de_DE.UTF-8
-LINES=60
+LINES=24
+MINTTY_SHORTCUT='/c/ProgramData/Microsoft/Windows/Start Menu/Programs/Cygwin/Cygwin64 Terminal.lnk'
-PPID=1
+PPID=1470
+PROMPT_COMMAND='history -a; cwdtitle'
+PROMPT_DIRTRIM=3
-RANDOM=3545
+RANDOM=27276
-SECONDS=10
+SECONDS=18
+SHELL=/bin/bash
+SHLVL=2
-TERM=xterm-256color
+TERM=xterm
+TERM_PROGRAM=mintty
+TERM_PROGRAM_VERSION=3.4.6
-TTY=/dev/cons0
+TTY=/dev/pty0
-ZSH_ARGZERO=/usr/bin/zsh
+ZSH_ARGZERO=zsh
-_ZSH_AUTOSUGGEST_CHILD_PID=1616
+_ZSH_AUTOSUGGEST_CHILD_PID=1533
-temp=''
-tmp=''

[ericfreese]

Thank you so much for digging into this so thoroughly. At this point, I think it must be some combination of your console, oh-my-zsh, and this plugin (in async mode). Is there anything more that you can chop out of oh-my-zsh to try to find what in there might be causing the trouble?

[dbachran]

Hm... I was somehow hoping you could give me some further pointers. 😉 I am out of ideas, currently. And I am neither familiar with oh-my-zsh, zsh-autosuggestions, and how this async mode is being implemented. If there is anything I could try out, I'd greatly appreciate further pointers to investigate.

[ericfreese]

Can you give the output of setopt with that minimal .zshrc file you had? And also the output of setopt from zsh -df with zsh-autosuggestions sourced manually?

[ericfreese]

Another thing to try is commenting out parts of your ~/.oh-my-zsh/oh-my-zsh.sh or parts of the files under ~/.oh-my-zsh/lib/ to see if you can find which parts of it are responsible

[dbachran]

Thanks for your ideas. Here the setopt output first.

Default setopt:

alwaystoend
autocd
autopushd
completeinword
extendedhistory
noflowcontrol
histexpiredupsfirst
histignoredups
histignorespace
histverify
interactive
interactivecomments
login
longlistjobs
monitor
promptsubst
pushdignoredups
pushdminus
sharehistory
shinstdin
zle 

setopt after zsh -df and manually sourced zsh-autosuggestions:

noglobalrcs
interactive
monitor
norcs
shinstdin
zle 

And for completeness, setopt from within Cygwin Terminal (mintty.exe) with bash, and manually executed zsh:

alwaystoend
autocd
autopushd
completeinword
extendedhistory
noflowcontrol
histexpiredupsfirst
histignoredups
histignorespace
histverify
interactive
interactivecomments
longlistjobs
monitor
promptsubst
pushdignoredups
pushdminus
sharehistory
shinstdin
zle 

The only missing option here is login, which kind of makes sense, since I executed zsh without further options from within bash . Whereas from the custom Console terminal, zsh --login is being executed.

[dbachran]

Ok, I found another thing, which is also pointing towards something within the terminal. When commenting out the custom ZLE widget funtionality of zle-line-init below in key-bindings.zsh, zsh-autosuggest is working fine within my custom console (https://github.com/cbucher/console) with async mode enabled.

--- a/lib/key-bindings.zsh
+++ b/lib/key-bindings.zsh
@@ -6,7 +6,7 @@
 # only then values from $terminfo are valid
 if (( ${+terminfo[smkx]} )) && (( ${+terminfo[rmkx]} )); then
   function zle-line-init() {
-    echoti smkx
+    # echoti smkx
   }
   function zle-line-finish() {
     echoti rmkx

There seems to be something broken regarding the terminal interpretation of smkx which I can confirm. See the following example:

/d/workspace$ echoti smkx
/d/workspace$ echoti r←[?1h←[?1h←[?1hm←[?1h←[?1h←[?1hk←[?1h←[?1h←[?1hx←[?1h←[?1h←[?1h
/d/workspace$ now, everything is workfing fine, again

After manually executing echoti smkx, almost every keystroke is getting garbled, as soon as zsh-autosuggest does not have any suitable suggestion anymore.

This does not happen with async mode disabled, though.

[ericfreese]

Awesome, thanks again. So, is it correct that this would be a minimal ~/.zshrc that would reproduce this problem without oh-my-zsh?

function zle-line-init() { echoti smkx }
function zle-line-finish() { echoti rmkx }
source path/to/zsh-autosuggestions.zsh

If so, maybe you can dig further to see where in this plugin's async code path is triggering the characters to be printed. The code related to the async functionality is here: https://github.com/zsh-users/zsh-autosuggestions/blob/a411ef3e0992d4839f0732ebeb9823024afaaaa8/zsh-autosuggestions.zsh#L757-L831

Can you try temporarily adding a sleep 4 line to the process that is spawned to fetch the suggestion in the background? I'm thinking that adding it on this line would be useful. And then you can tell if the garbled characters are added before or after the long pause while it is trying to fetch a suggestion.

You may be able to investigate further by commenting out parts of the zsh-autosuggestions code and/or adding debug echo/printf statements.

Also FWIW, it looks like the added characters ←[?1h are related to this but with the escape character being replaced with a left arrow for some reason xxx.

[ericfreese]

One more thing to maybe try. Can you paste the result of running this? infocmp -1 | grep '[rs]mkx'

[dbachran]

You are right, this is a minimal ~/.zshrc to trigger this behaviour (need to also load/overwrite the predefined ZLE widgets):

function zle-line-init() { echoti smkx }
function zle-line-finish() { echoti rmkx }
zle -N zle-line-init
zle -N zle-line-finish
source ~/.oh-my-zsh/custom/plugins/zsh-autosuggestions/zsh-autosuggestions.zsh

This is the output of infocmp -1 | grep '[rs]mkx':

        rmkx=\E[?1l\E>,
        smkx=\E[?1h\E=,

After adding a sleep 4 as indicated, I get the following output:

Ted% a←[?1h←[?1ab←[?1h←[?1hc←[?1h
zsh: command not found: abc
Ted% abcd←[?1h←[?1h
zsh: command not found: abcd
Ted%

Note and further observations:

1. I type a and wait 4 seconds until the first ←[?1h appears
2. When typing b an intial ←[?1h immediately appears before b, and the second ←[?1h appears 4 seconds later
3. Same for c
4. Hitting enter also adds another ←[?1h before processing the (unknown) command, no further ←[?1h appears afterwards
5. Typing abc does not produce any characters (this is known already now)
6. Typing a d produces another ←[?1h after 4 seconds
7. Hitting enter adds another ←[?1h again before processing the (unknown) command

tl;dr Garbled characters are added before (immediately) and after (after 4 seconds) the character.

[dbachran]

Interestingly, when adding an echo statement within the widget function declarations (see patch below), I do not get any garbled characters anymore, but the echo statement instead. See output below.

Patch:

Ted% git diff
diff --git a/zsh-autosuggestions.zsh b/zsh-autosuggestions.zsh
index b19cac7..f214ef8 100644
--- a/zsh-autosuggestions.zsh
+++ b/zsh-autosuggestions.zsh
@@ -472,6 +472,7 @@ _zsh_autosuggest_partial_accept() {
        local action
        for action in $_ZSH_AUTOSUGGEST_BUILTIN_ACTIONS modify partial_accept; do
                eval "_zsh_autosuggest_widget_$action() {
+                       echo Z:$action
                        local -i retval

                        _zsh_autosuggest_highlight_reset
@@ -791,6 +792,8 @@ _zsh_autosuggest_async_request() {
                # Tell parent process our pid
                echo $sysparams[pid]

+               sleep 4
+
                # Fetch and print the suggestion
                local suggestion
                _zsh_autosuggest_fetch_suggestion "$1"

Output:

Ted% Z:modify
aZ:suggest
Z:modify
abZ:suggest
Z:modify
cZ:suggest
Z:clear

zsh: command not found: abc
Ted%

Notes:

1. I type a and get Z:modify<enter>a, and after 4 seconds Z:suggest
2. I type b and get Z:modify<enter>ab, and after 4 seconds Z:suggest: Why is the a repeated here?
3. I type c and get Z:modify<enter>c, and after 4 seconds Z:suggest
4. I type enter and get Z:clear<enter>

[stanica]

Any updates on this? I'm getting the garbled characters when using Windows Terminal and the built-in terminal to VS Code. Git Bash seems to work fine, but only in the standalone terminal. Git Bash In VS Code is broken. Using v0.6.4 fixes the garbled text but the cursor briefly jumps back a character every time I enter a new character that's part of an autocompleted command.

[CervEdin]

I'm pretty sure this is a bug in the windows terminal and how it treats ANSI escape codes. There are others similar reports like this openjdk and this coc. You can try and enable legacy console to and see if it resolves the issue

[dbachran]

Oh, but I noted the following: I am using a custom console on Windows (https://github.com/cbucher/console), where I am seeing this issue. When trying to reproduce this issue with the Cygwin Terminal (mintty.exe) I do not get those funny characters. So there seems to be something different with regards to how these terminals/consoles behave?

I haven't tried Windows terminal, yet. (Actually, I don't even have it installed.)

All I want to say is: There are other consoles affected, as well.

[CervEdin]

I'm wondering if it has to do with the windows code page setting. I have a different machine with similar configuration where I don't see this issue. It has the code-page set to utf-8

[CervEdin]

I was able to solve the seemingly related issue by

changing the windows code page to utf-8 as per resolved the issue on my machine

[ninagrosse]

I'm having the same problem with Git Bash, zsh and oh-my-zsh on Windows 10. However, not all terminals seem to be affected. I'm mostly using Tabby (https://github.com/Eugeny/tabby) and the integrated terminal of VSCode.

When launching Git Bash via Tabby, it uses $TERM=cygwin which doesn't cause any issues. When I change it to $TERM=xterm-256color, the funny characters appear when entering a command with no availabe suggestions. VSCode terminal seems to use $TERM=xterm-256color by default, so same problem here. However, the default terminal of Git Bash (MINGW64 / MSYS2) doesn't have this problem when setting it to xterm-256color.

The workaround with disabling async mode via unset ZSH_AUTOSUGGEST_USE_ASYNC fixes the problem when using xterm-256color in Tabby and VSCode.

[ngoc199]

You can use this:

cd ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions
git checkout tags/v0.6.4 -b v0.6.4-branch

Since the changes made by @kevindqc work, could someone consider merging this to the current version?

[izancalderaro]

You can use this:

cd ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions
git checkout tags/v0.6.4 -b v0.6.4-branch

Works to me, thx!

[mbwhite]

FYI I've exactly this issue and I didn't have zsh-autosuggestions installed; this is using windows terminal.. So I think the issue is more the terminal.