Kitty: powerlevel10k support

[mortezadadgar]

kitty doesn't sacle text(or glyphs) when new terminal windows open up horizontally, I played with some config(like resize_draw_strategy) but non of them worked

[kovidgoyal]

If you want to change the font size in kitty, you use the shortcuts for
that, ctrl++ and ctrl+-. Resizing does not change font sizes.

[flipflop133]

Kitty:

Alacritty:

I have the same issue which I don't have in other terminal.
When I open new terminal in "split-h" mode in I3 it's duplicating the prompt text.

[Luflosi]

I can confirm that resizing the window can duplicate the prompt. This is not the case in iTerm2 and Alacritty.

[kovidgoyal]

Nonsense, prompt duplication is entirely timing/resize type dependent. For example, five seconds of googling finds: https://github.com/alacritty/alacritty/issues/2866

[kovidgoyal]

When you use a fancy prompts that extend to the right edge of the screen, you are going to have these issues, in ALL terminals. That is simply a side effect of text reflow on terminal resize. The shell redraws the prompt on the current line, but after a resize it has no way of knowing whether the cursor is on a new line or the last prompt line.

[kovidgoyal]

And just for completeness, from powerlevel10k's own FAQ: https://github.com/romkatv/powerlevel10k#horrific-mess-when-resizing-terminal-window

[mortezadadgar]

And just for completeness, from powerlevel10k's own FAQ: https://github.com/romkatv/powerlevel10k#horrific-mess-when-resizing-terminal-window

So why not disable text reflowing or at least make it configurable.

[kovidgoyal]

Because if you dont reflow that means you lose text when the terminal
is shrunk. That is really not acceptable. The proper solution for this
issue is to create an escape code that marks lines as "do not reflow if
under cursor". Then the shell, in this case zsh would have to be changed emit those
escape codes for its prompt lines. Terminals could then use this
information, to not reflow such lines on shrink if the cursor is on a
block of such lines at the time of the resize.

[romkatv]

And just for completeness, from powerlevel10k's own FAQ: https://github.com/romkatv/powerlevel10k#horrific-mess-when-resizing-terminal-window

Zsh patch mentioned in that FAQ entry works with Kitty.

[kovidgoyal]

@romkatv You interested in the proper fix I mentioned above? If so, I can look into implementing it in kitty. Basically before drawing every line of the prompt you would need to emit an escape code, the terminal emulator would then mark those lines as belonging to a prompt and at resize time if the cursor is on a prompt line, it will not reflow the entire block of prompt lines.

[romkatv]

@kovidgoyal If you implement it, I'll use it.

[kovidgoyal]

Before I do, you have any feedback on design? A simple, single escape
code to mark a line as a prompt line is sufficient?

[romkatv]

I don't understand the suggested design sufficiently enough to have an opinion. Could you clarify what the new escape code will do?

[kovidgoyal]

when the terminal emulator receives the escape code, it marks the
current line (i.e. the line the cursor is on) as a "prompt line". That
is all.

When the terminal is resized, if the cursor is on a previously marked
"prompt line" the terminal will not reflow text in the block of one or
more contiguous prompt lines containing the cursor. Further if before
the resize the cursor is on the "nth" prompt line in the block, after
the resize the terminal emulator will guarantee that the cursor remains
on the "nth" prompt line of the block. In other words, while the
location of the entire block might move up or down the screen, the
relative vertical position of the cursor will remain unchanged.

[romkatv]

It's not obvious whether it'll be possible to use this from zsh. Maybe if zle (Zsh Line Editor) emits this escape code on every character, then it would work. It's weird though.

What zsh needs is the ability to move back to the position where the current prompt starts. Everything after that position is the area that zle controls. It moves freely in that area and repaints things. Not all of that content is prompt.

If you can implement some protocol that would allow disabling reflow starting from a marked line, that would work. I think this would require two escape codes: one to disable reflow, and another to enable it.

If you can implement the equivalent of sc/rc that sticks to the terminal content and doesn't move on scroll, that would also work.

For me personally this issue is of no importance, so please don't implement anything for my sake. I don't use Kitty myself.

[kovidgoyal]

On Mon, Jun 01, 2020 at 02:06:40AM -0700, Roman Perepelitsa wrote:

It's not obvious whether it'll be possible to use this from zsh. Maybe if zle (Zsh Line Editor) emits this escape code on every character, then it would work. It's weird though.

What zsh needs is the ability to move back to the position where the current prompt starts. Everything after that position is the area that zle controls. It moves freely in that area and repaints things. Not all of that content is prompt.

That is much simpler, so two escape codes, one to "mark" a line
one to move the cursor back to the previously marked line. With
the mark being moved during reflow along with the terminal text.
Sounds OK?

So whenever zsh draws a prompt it first emits this escape code. And
whenever it receives a resize notification it first emits the escape
code to move cursor back to the last marked position
and then redraws the prompt and whatever comes below it.

[romkatv]

Yep, that would work. My zsh patch does pretty much that. It uses the standard sc/rc escape codes to save/restore cursor position. However, when the windows is scrolled by adding lines at the bottom, the position of the saved cursor moves relative to the text. This complicates code a little bit but not much.

I should also note that my patch will likely never make it to Zsh. I have commit rights to the Zsh repo but I wouldn't commit non-trivial things without consensus. There is no consensus and no way forward that I could see. I don't think an alternative patch to Zsh that uses kitty-specific escape codes would fare any better.

[kovidgoyal]

On Mon, Jun 01, 2020 at 02:34:40AM -0700, Roman Perepelitsa wrote:

Yep, that would work. My zsh patch does pretty much that. It uses the standard sc/rc escape codes to save/restore cursor position. However, when the windows is scrolled by adding lines at the bottom, the position of the saved cursor moves relative to the text. This complicates code a little bit but not much.

I'm surprised sc/rc would work for this, since reflow means that a
pre-reflow line and column position is pretty meaningless.

I should also note that my patch will likely never make it to Zsh. I have commit rights to the Zsh repo but I wouldn't commit non-trivial things without consensus. There is no consensus and no way forward that I could see. I don't think an alternative patch to Zsh that uses kitty-specific escape codes would fare any better.

That's a shame, because without buy in from users of the new escape
code, I dont really have any incentive to add the code
complication/resource usage overheads to kitty.

So if you do manage to get buy in from zsh, let me know and I will
be happy to work with you to implement a robust solution for this.

Although does this really need significant changes to zsh at all?
You basically need to emit the mark escape code before every prompt draw
and on resize emit the restore escape code before doing anything else.
It's literally emitting like 5 bytes that will have no effect on
terminal emulators that dont support this protocol. I am amazed this
would be controversial, but then I dont know the zsh community at all.
Maybe there are already extensive hacks for trying to handle reflow and
this would be hard to integrate?

[romkatv]

I'm surprised sc/rc would work for this, since reflow means that a pre-reflow line and column position is pretty meaningless.

Saved cursor position reflows on all terminals except Alacritty if I remember correctly. This is a really nice property.

Although does this really need significant changes to zsh at all?

It's a small change. My existing patch is small, too. It got stuck because there is not a single zsh dev who actually cares about this issue (neither do I) and because one zsh dev expressed a concern that it might break something. I've asked a couple times what my patch could break but didn't get a reply.

So if you do manage to get buy in from zsh, let me know and I will be happy to work with you to implement a robust solution for this.

I won't attempt again to get a buy-in for this. The resizing issue is too minor to spend my social capital on it. Maybe someone else will give it a try.

---

By the way, if instead of adding the new and better equivalents of sc/rc you add escape codes that disable text reflow after the marked point, these could be used by Zsh themes without making any changes in Zsh proper. Basically, PS1 will start with "disable reflow from here" escape code, and before executing a command (this is preexec hook in zsh) the theme will print "reflow everything once again" escape code.

[kovidgoyal]

On Mon, Jun 01, 2020 at 03:24:05AM -0700, Roman Perepelitsa wrote:

I'm surprised sc/rc would work for this, since reflow means that a pre-reflow line and column position is pretty meaningless.

Saved cursor position reflows on all terminals except Alacritty if I remember correctly. This is a really nice property.

It definitely doesn't reflow on kitty as well. I dont remember writing
any code to make it do so :)

By the way, if instead of adding the new and better equivalents of sc/rc you add escape codes that disable text reflow after the marked point, these could be used by Zsh themes without making any changes in Zsh proper. Basically, PS1 will start with "disable reflow from here" escape code, and before executing a command (this is preexec hook in zsh) the theme will print "reflow everything once again" escape code.

Hmm might be worth considering, then.