Closed majutsushi closed 4 months ago
I'm not quite sure if I understand you correctly. If you're referring to the space around the icon text, indeed there is space:
That's interesting, because in the actual byte output the space isn't there. I suspect it gets replaced with the cursor positioning escape code <Esc>[24;23H
at some later point. I don't know where that's coming from, I can't really immediately see its purpose. I'd like to dig deeper but I probably won't have time for that in the next few days.
Does the text line of this file you copied from the TUI contain spaces?
I just tested using the latest version of kitty and the latest Yazi code, but couldn't reproduce the issue.
It's possible that it has been fixed from either side. What version of kitty are you using? I noticed you are not using the latest Yazi code. Could you try the latest Yazi code to see if the problem has been resolved?
I can still reproduce it with Kitty 0.33.1 (the latest release) and the latest Yazi commit, but only under certain conditions that I haven't been able to reduce to a simple reproducible example yet. I'll try to have a closer look next week.
What I've discovered so far is that it happens for completely unstyled icons (i.e. icons for unknown filetypes with the default config) that also otherwise haven't had any kind of styles applied, for example once I have "hovered" over such a file (and thus applied the "reverse" style) it has the right size, even after I've moved the selection to another file.
I don't think it is the "styling" itself that is responsible for this, I think the act of styling just replaces the cursor positioning escape code I mentioned above with a space. Why that happens I don't really know though.
Hmm I'm not quite sure how to resolve it, it seems the only thing Yazi can do (as per kitty's requirement) is to add spaces around the icons, but I've already added it, though the requirement is quite weird, and kitty is the only terminal I know of that requires this.
So I prefer keeping the current solution, i.e. adding it to the FAQ, and suggesting users use a flavor to "workaround" it. I'm going to close this issue, if you find more clues that can help resolve, please reply to this issue, and I will reopen it.
though the requirement is quite weird, and kitty is the only terminal I know of that requires this.
because other terminal will leak glyphs into neigboring cells which is often even more broken.
if yazi isnt sending cursor reposition, then its probably ratatui that is doing that. strange that it stays fixed after being hovered.
yep, drawing Paragraph::new(" ")
from ratatui reproduces this.
I'm going to lock this issue because it has been closed for 30 days. ⏳ This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
What system are you running Yazi on?
Linux X11
What terminal are you running Yazi in?
Kitty 0.33.1
Did you try the latest code to see if this problem got fixed?
Tried, but the problem still
yazi --debug
outputDescribe the bug
This bug is already mentioned at https://yazi-rs.github.io/docs/faq#why-icons-shrink, however I think I figured out what the problem is. The same kind of bug was recently filed in relation to joshuto: https://github.com/kovidgoyal/kitty/issues/7292
This pointed me towards Kitty's
--dump-bytes
option, which indicated that the problem in yazi is the same: in some cases there's no space after an icon. For icons that have the right size the bytes are<Esc>[38;2;137;224;81m <Icon> <Esc>[39m<filename>
, whereas for incorrectly sized ones it is<Icon><Esc>[24;23H<filename>
. So there is a space missing after the icon, causing it to have the wrong size. I haven't had time to check the code but hopefully this should be easy to fix.Expected Behavior
Icons need a space after them so they have the right size
To Reproduce
Run yazi in Kitty without a flavor configured
Configuration
No response
Anything else?
No response