Konsole: garbled after applying theme

[Nuc1eoN]

So theme.sh works great for me on terminals like alacritty or foot.

But on Konsole, it's completely garbled:

It is using libvte so shouldn't it support OSC 4/11 ?

[rvaiya]

I think konsole does its own emulation (it doesn't use vte), however it does appear to support the necessary escape codes. I just tested the latest version of konsole on my archbox and it seems to work. Are you using the latest version of theme.sh?

[Nuc1eoN]

Hey yeah I also find it a little weird, I am on v1.0.1.

[rvaiya]

The latest version of the script is 1.1.5, so you may want to upgrade. There have been several bug fixes and additional themes since the original release.

[Nuc1eoN]

Oh ok good to know, I was on https://aur.archlinux.org/packages/theme.sh which is apparently outdated.
However maybe you should update your tags, latest one is still at 1.0.7 https://github.com/lemnos/theme.sh/tags

Anyways, sadly it does not fix the issue though :/
Konsole 21.12.1 btw.

[pjvds]

@rvaiya is it correct that the latest release tag is 1.0.7? I'm maintaining the Arch package build for theme.sh and would like to bump it to 1.1.5 to support the latest version.

[Nuc1eoN]

Ok I have just figured out how to reproduce the issue:

Under Edit Pofile -> General -> Edit environment variables
For some reason it says there for me:

TERM=xterm-256color
COLORTERM=truecolor

I have found out that COLORTERM=truecolor is causing the issue. I never remember putting it there though.

EDIT:
Starting alacritty or foot with COLORTERM=truecolor does not cause any issues apparently. A konsole bug?

EDIT2:
@rvaiya however I wonder why you couldn't reproduce this, apparently TERM=xterm-256color and COLORTERM=truecolor is added by default to konsole since 2016

[lemnos]

@pjvds

is it correct that the latest release tag is 1.0.7? I'm maintaining the Arch package build for theme.sh and would like to bump it to 1.1.5 to support the latest version.

Oops, looks like like the tags were sitting in my local repo. I have updated them now, thanks for letting me know. Perhaps you might consider making a -git package which always uses the latest commit. I don't anticipate too many backwards incompatible changes at this point.

@Nuc1eoN

I have found out that COLORTERM=truecolor is causing the issue. I never remember putting it there though.

It is unclear from your original post whether or not you are having a problem with interactive mode or the script
as a whole (e.g does theme.sh gruvbox work?). I assumed the latter.

Starting alacritty or foot with COLORTERM=truecolor does not cause any issues apparently. A konsole bug?

Setting colorterm just causes the script to assume truecolor support which means it will try and paint the colors in the preview window rather than changing the theme colors on the fly (falling back to -i2). You can force the latter behaviour by explicitly specifying the -i2 flag. If you set COLORTERM on a terminal which doesn't support truecolor then the script will break, however konsole does seem to support truecolor and works for me without issue, so this shouldn't be causing a problem.

I am testing on 21.12.1.

[rvaiya]

I should note that even though the colors change it requires new content to be printed to the screen or the window to be refocused before the changes take effect. This indeed appears to be a konsole bug, but it might be related to the fact that I am running it outside of KDE.

[Nuc1eoN]

It is unclear from your original post whether or not you are having a problem with interactive mode or the script
as a whole (e.g does theme.sh gruvbox work?). I assumed the latter.

Ok sorry if my bug description was unclear:

theme.sh gruvbox

Produces garbled text when when konsole is started with COLORTERM=truecolor. The changes are immediate for the whole visible area independent of this setting.

[rvaiya]

Produces garbled text when when konsole is started with COLORTERM=truecolor. The changes are immediate for the whole visible area independent of this setting.

That is indeed quite odd. The COLORTERM variable is only inspected in interactive mode. The output should be identical if you run COLORTERM= theme.sh gruvbox and COLORTERM=truecolor theme.sh gruvbox. I assume you are using the latest version (1.1.5).

[Nuc1eoN]

@rvaiya Yes when I do that the output is identical.

I was talking about starting konsole with that environment variable.
When I start konsole with

COLORTERM= konsole

theme.sh gruvbox works fine. (Be sure to remove the environment var also from konsoles setting so it doesnt interfere)

When starting console with

COLORTERM=truecolor konsole

theme.sh gruvbox will produce garbled output.

Yes I am running v1.1.5

[rvaiya]

COLORTERM=truecolor konsole

This still works for me. What is your konsole --version?

[Nuc1eoN]

Yes I know, by default konsole has COLORTERM=truecolor set, so it is weird to me that it does not happen on your side (unsetting COLORTERM=truecolor is kind of my workaround for now).

My konsole version is 21.12.1 on ArchLinux.

@pjvds @lemnos would you maybe be so kind and see if you can reproduce the issue on your side?
To reproduce it, it should be enough to install and open konsole, type theme.sh gruvbox and see if your text is garbled thereafter.

[Nuc1eoN]

Progressing a little bit here. It seems this is not happening in a bash session. But it is happening for me with zsh.

I have powerlevel10k and zsh4humans installed not sure if that interferes.

UPDATE:
Yep so something about zsh4humans makes it break. As soon as I comment out z4h init || return in my .zshrc the issue disappears.

UPDATE 2:
I could now nail it down further to the tmux usage of z4h. When I explicitely disable it in my .zshrc with zstyle ':z4h:' start-tmux 'no' the bug disappears.

[lemnos]

I could now nail it down further to the tmux usage of z4h. When I explicitely disable it in my .zshrc with zstyle ':z4h:' start-tmux 'no' the bug disappears.

This makes more sense. tmux detection is a different beast altogether. Having said that, it seems
to be working for me. It might help if you post your .tmux.conf.

What is the output of tmux display-message -p '#{client_termfeatures}' within tmux in konsole?

You might want to try running tmux with an empty shellrc and empty (and populated) .tmux.conf to see if you can isolate the problem.

[Nuc1eoN]

@lemnos This issue is eating me up :D

The problem is that I cannot reproduce this with standalone tmux. Heck I do not even make use of tmux other than using zsh4human, which apparently uses tmux in a specific way that manages to break konsole (in conjunction with theme.sh).

So here are updated reproduction steps:

1. You need zsh set up with zsh4humans
2. (Re-)start konsole
3. Run theme.sh gruvbox

Now your chances of breaking are very high :D
Sadly I did not manage to break it with tmux standalone, which is also why I reported it to romkatv/zsh4humans#203

What is the output of tmux display-message -p '#{client_termfeatures}' within tmux in konsole?

$ tmux display-message -p '#{client_termfeatures}'
no server running on /tmp/tmux-1000/default

It must be how z4h uses tmux internally. I do not even have a .tmux.conf file.

[lemnos]

Now your chances of breaking are very high :D

I don't have time to try this right now, but I'll experiment later when I have some free time.

no server running on /tmp/tmux-1000/default

This would suggest tmux is not running.

Is this with or without zstyle ':z4h:' start-tmux 'no'? If it is the former, then it would appear to be to the case which doesn't break theme.sh (I need the output in the case which does).

zsh4humans seems to do a bunch of weird things. My guess is that zstyle ':z4h:' start-tmux 'yes' in conjunction with COLORTERM=truecolor is causing it to do something which interferes with the OSC sequences sent by theme.sh (my instinct would be something to do with escape codes in the prompt setting logic).

[Nuc1eoN]

I don't have time to try this right now, but I'll experiment later when I have some free time.

Totally understandable, sadly it is the only way I know it can be reproduced at this time.

This would suggest tmux is not running.

This would suggest it usually, but it seems z4h uses tmux in some unconventional way internally.

Is this with or without zstyle ':z4h:' start-tmux 'no'? If it is the former, then it would appear to be to the case which doesn't break theme.sh (I need the output in the case which does).

With zstyle ':z4h:' start-tmux 'yes' the issue occurs. (It is z4h's default behaviour, even if undefined in .zshrc.)
With zstyle ':z4h:' start-tmux 'no' the issue does not occur.

zsh4humans seems to do a bunch of weird things. My guess is that zstyle ':z4h:' start-tmux 'yes' in conjunction with COLORTERM=truecolor is causing it to do something which interferes with the OSC sequences sent by theme.sh (my instinct would be something to do with escape codes in the prompt setting logic).

This might be true. What strikes me as odd is that other terminals are handling it fine. Or at least kitty, alacritty, foot present do not exhibit this behavior.

[lemnos]

It seems z4h is broken and the author refuses to fix it. Details can be found in the issue you linked to. I am closing this for now.

[Nuc1eoN]

Following the conversation it seems to me, that theme.sh is broken, the author of z4h has even made the effort to provide a code example how to fix it. But I acknowledge the decision.

[lemnos]

The provided code is useless since theme.sh aims to be POSIX compliant. I am familiar with the referenced escape sequences and have deliberately chosen not to use them for performance reasons. They shouldn't be necessary in this case.

If the user's $TMUX variable is mangled by a piece of third party software then that is the fault of the software. You wouldn't change your $DISPLAY variable and then complain that you can't run X programs. Programs should not modify environment variables which belong to other programs, but I will let others come to their own conclusions.