dnkl/foot
41
2.0k
Fork
You've already forked foot
243

Percent characters printed when using powerlevel10k zsh theme #265

Closed
opened 2020年12月30日 15:59:51 +01:00 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.
Owner
Copy link

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 2020年12月31日 12:43:40 +01:00
  • closed this issue
  • added the
    not-a-bug
    label

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
Copy link

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 Branch/Tag specified
master
osc-5522
sixel-heap-buffer-overflow
releases/1.27
releases/1.26
releases/1.25
releases/1.24
multi-cursor
releases/1.23
pixman-16f-2
releases/1.22
releases/1.21
releases/1.20
releases/1.19
releases/1.18
releases/1.17
releases/1.16
releases/1.15
releases/1.14
releases/1.13
releases/1.12
releases/1.11
releases/1.10
releases/1.9
releases/1.8
releases/1.7
releases/1.6
releases/1.5
releases/1.4
releases/1.3
releases/1.2
releases/1.1
releases/1.0
1.27.0
1.26.1
1.26.0
1.25.0
1.24.0
1.23.1
1.23.0
1.22.3
1.22.2
1.22.1
1.22.0
1.21.0
1.20.2
1.20.1
1.20.0
1.19.0
1.18.1
1.18.0
1.17.2
1.17.1
1.17.0
1.16.2
1.16.1
1.16.0
1.15.3
1.15.2
1.15.1
1.15.0
1.14.0
1.13.1
1.13.0
1.12.1
1.12.0
1.11.0
1.10.3
1.10.2
1.10.1
1.10.0
1.9.2
1.9.1
1.9.0
1.8.2
1.8.1
1.8.0
1.7.2
1.7.1
1.7.0
1.6.4
1.6.3
1.6.2
1.6.1
1.6.0
1.5.4
1.5.3
1.5.2
1.5.1
1.5.0
1.4.4
1.4.3
1.4.2
1.4.1
1.4.0
1.3.0
1.2.3
1.2.2
1.2.1
1.2.0
1.1.0
1.0.0
0.9.0
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
dnkl/foot#265
Reference in a new issue
dnkl/foot
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?