Percent characters printed when using powerlevel10k zsh theme #265

Closed
opened 1 year ago by zsolt-donca · 3 comments

Some wierd percent characters are printed to the console when using the zsh theme powerlevel10k:

image

The wierd thing is that this seems to be performance-related. When using individual foot processes, the issue is always present. However, in the client-server architecture, the the first footclient window always have the issue, but it is random for the subsequent footclient windows: if I keep spawning serveral windows at once (by keeping mod+Enter pressed), then most of the windows will have the issue, but if I spawn the footclient windows with enough delay, then only the first one will have, and the subsequent one probably won't.

I've tried various powerlevel10k configurations, and the issue is present with all of them, including the simplest ones. I've even tried disabling the instant prompt, but there doesn't seem to be any effect.

These characters are not printed in any of the other terminals that I have installed: kitty, alacritty, terminator, gnome-terminal.

Some wierd percent characters are printed to the console when using the zsh theme [powerlevel10k](https://github.com/romkatv/powerlevel10k): ![image](/attachments/62a92b9d-e952-4b44-8957-5af5d132c526) The wierd thing is that this seems to be performance-related. When using individual `foot` processes, the issue is always present. However, in the client-server architecture, the the first `footclient` window always have the issue, but it is random for the subsequent `footclient` windows: if I keep spawning serveral windows at once (by keeping `mod+Enter` pressed), then most of the windows will have the issue, but if I spawn the `footclient` windows with enough delay, then only the first one will have, and the subsequent one probably won't. I've tried various powerlevel10k configurations, and the issue is present with all of them, including the simplest ones. I've even tried disabling the instant prompt, but there doesn't seem to be any effect. These characters are not printed in any of the other terminals that I have installed: kitty, alacritty, terminator, gnome-terminal.
dnkl commented 1 year ago
Owner

This is actually not related to the powerlevel10k theme; it's a generic zsh issue. It's a timing issue, and has to do with how zsh responds to window resize events.

While foot is launching, it is possible for the shell to observe (by polling, or through SIGWINCH signals) multiple window sizes:

  • The first size is a hardcoded 80x24 chars grid. This is before the window has been displayed, or even created.
  • Next, assuming you're running Sway at least, the compositor asks us to size the window. This is still before the window is visible. Here, foot will use the configured initial-window-size-pixels setting.
  • After finally becoming visible, Sway immediately asks us to resize ourselves to the final size.

This quick succession of size changes can trigger racy behavior in client applications. Foot is not the only terminal that exhibits this (search Alacritty's issue tracker and you'll find several reports).

It may be slightly more inclined to show this behavior though, since it is pretty aggressive about spawning the shell process as early as possible. This is to reduce startup time.

Related (probably at least) issue for a different shell: #195

While I can't say for sure what the '%' characters are, my guess would be that they are related to the shell redrawing its prompt.

This is actually _not_ related to the powerlevel10k theme; it's a generic zsh issue. It's a timing issue, and has to do with how zsh responds to window resize events. While foot is launching, it is possible for the shell to observe (by polling, or through `SIGWINCH` signals) multiple window sizes: * The first size is a hardcoded 80x24 chars grid. This is **before** the window has been displayed, or even created. * Next, assuming you're running Sway at least, the compositor asks **us** to size the window. This is _still_ before the window is visible. Here, foot will use the configured `initial-window-size-pixels` setting. * After _finally_ becoming visible, Sway immediately asks us to resize ourselves to the final size. This quick succession of size changes can trigger racy behavior in client applications. Foot is **not** the only terminal that exhibits this (search Alacritty's issue tracker and you'll find several reports). It _may_ be slightly more inclined to show this behavior though, since it is pretty aggressive about spawning the shell process as early as possible. This is to reduce startup time. Related (probably at least) issue for a different shell: https://codeberg.org/dnkl/foot/issues/195 While I can't say for sure _what_ the '%' characters _are_, my guess would be that they are related to the shell redrawing its prompt.
dnkl closed this issue 1 year ago
dnkl added the
not-a-bug
label 1 year ago
Poster

I would like to add this that I've been using foot as my main and only terminal since December, and never actually noticed this issue in practice. I think it was only manifested while testing and not an issue at all in real life.

Now that I'm here, I would like to add that foot is a great terminal, and I'm loving it. @dnkl keep up the good work!

I would like to add this that I've been using `foot` as my main and only terminal since December, and never actually noticed this issue in practice. I think it was only manifested while testing and not an issue at all in real life. Now that I'm here, I would like to add that `foot` is a great terminal, and I'm loving it. @dnkl keep up the good work!
Owner

Now that I'm here, I would like to add that foot is a great terminal, and I'm loving it. @dnkl keep up the good work!

Thanks for the kind words! It certainly helps to keep the motivation up :)

> Now that I'm here, I would like to add that foot is a great terminal, and I'm loving it. @dnkl keep up the good work! Thanks for the kind words! It certainly helps to keep the motivation up :)
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.