ANSI codes inserted into the prompt after starting broot (causing "No matching verb")

[Gelio]

After starting br or broot in my terminal, I see the following ANSI codes inserted immediately:

It says: 11;rgb:2828/2a2a/3636

This happens regardless of whether I run the command in zsh, bash (with the default bash prompt), inside or outside tmux.

The only difference is that when I run it outside tmux, broot does not say "No matching verbs", but it behaves as if the sequence was not there:

I am not sure what is causing this. I would appreciate any tips to debug this issue.

[Canop]

This is related to the test of terminal colors.

Assuming you're using version 1.36 of broot, can you please see if it happens for you with version 1.32 ?

[Gelio]

You are right, this problem does not occur on 1.32.0

Kapture.2024-03-10.at.12.00.19.mp4

For reference, I am using kitty 0.32.2

[Canop]

@Gelio I don't know if you're able to compile things for rust.

If so, I would appreciate if you could test the example of https://github.com/Canop/xterm-query/ which is executed with cargo run --example kitty

[Gelio]

I understand you wanted me to run cargo run --example kitty from that repo.

Here is the output in kitty in tmux:

Here is the output in kitty outside of tmux:

The extra codes in my prompt were inserted automatically. The screenshots contain the state right after the command finished

[Canop]

What's your terminal and OS exactly ?

[zeenix]

Strange. Ironically my commit in xterm-query introducing this issue is exactly the solution to the symptoms here (at least on Linux) that I reported in Canop/terminal-light#4.

[Gelio]

What's your terminal and OS exactly ?

Terminal: kitty 0.32.2

OS: macOS Sonoma 14.2.1

[Gelio]

Here is the output from macOS default terminal app:

[zeenix]

@Gelio Thanks for providing the example run. I was about to reproduce this issue. I think Canop/xterm-query#4 fixes this since I'm not able to reproduce the issue when using the branch of that PR.

[zeenix]

@Gelio just out of curiosity, was broot working fine on Mac before recently?

[Gelio]

@Gelio Thanks for providing the example run. I was about to reproduce this issue. I think Canop/xterm-query#4 fixes this since I'm not able to reproduce the issue when using the branch of that PR.

I checked out that commit and it looks like the problem is fixed for me on kitty

Kitty in tmux:

Kitty outside of tmux (says image protocol is supported, as expected):

Interestingly, the macOS Terminal app still has the extra characters:

@Gelio just out of curiosity, was broot working fine on Mac before recently?

I switched to Mac recently and I can't tell, as I haven't used broot a lot recently :/ sorry

[zeenix]

I checked out that commit and it looks like the problem is fixed for me on kitty

Nice! Thanks so much for testing.

Interestingly, the macOS Terminal app still has the extra characters:

That's just the Terminal app being silly AFAICT. If you revert the commit to before my recent changes (git checkout abfb5aae9e7539cb9cd3c8b3fcc98a7dfa5e6276) and run the example, you'll still see those. I'd just say do what everyone does on Mac: stick to iTerm2. :)

@Gelio just out of curiosity, was broot working fine on Mac before recently?

I switched to Mac recently and I can't tell, as I haven't used broot a lot recently :/ sorry

No worries. I can verify that at least kitty worked fine before my recent changes. My own app (gimoji) didn't work correctly though when launched from a git hook. In any case, I think we've now a fix for all that is fixable. :)

[CarterLi]

Same issue for iTerm in macOS

[Canop]

The fix has been released with version 1.36.1 @CarterLi @zeenix @Gelio

[Gelio]

I just upgraded and the problem no longer exists for me on Kitty (both in and outside of tmux)

Thanks @Canop and @zeenix for delivering a quick fix 🚀