zellij: Sixel images distorted; sixel images have too much bottom padding; sixel causes buffer full error

Hi, is there any progress on this? I just checked again with the current version and on my end the behavior is still the same

I have performed the steps requested to rebuild with the addition logging enabled and attached a video of myself re-creating the issue on a Debian12 amd64 host.

Also attached are the logs generated by both the standard and rebuilt executables.

Video: https://user-images.githubusercontent.com/84841307/226175132-c579adc4-1eb6-4063-a0bb-d8d2fe4e66d8.mov

Logs:

• zellij-additional-logging.log

• zellij-default.log

EDIT: I was wrong, see jessebot’s comment below

OLD TEXT: Looks like this issue was only reproducible when using iterm2. We switched to using wezterm on MacOS/Linux and are no-longer seeing this bug 🤷

Alright! Looks like we have no choice but to do this the hard way. 😃

I’m going to ask you to have Zellij log all the render messages it sends to your terminal so that I can go through them manually and figure out what’s going on here.

To do this, please add this line:

log::info!("output: {:?}", output.as_bytes());

above this line here: https://github.com/zellij-org/zellij/blob/main/zellij-client/src/lib.rs#L405

Then recreate the issue (with as few interactions with your terminal as possible so as not to inflate the log too much) and attach the contents of zellij.log (no need to attach the other files or to run Zellij with --debug) here.

Thanks!

That’s very heartening to hear! Sounds like you did a cool job despite being put on the spot like that. Thanks for helping spread the word, and I hope you get the job (if you want it 😃)!

I might bug you in the future when I have to demonstrate the tool to DevOps people, since the last time I did any serious work in that space, Chef was all the rage 😃

Hey @jessebot - now it’s my turn to apologize for the delay!

So, I have a guess - if you’re willing to try and build Zellij from main and change some minor stuff?

Basically, I want to change these values: https://github.com/zellij-org/zellij/blob/main/zellij-server/src/os_input_output.rs#L53-L54 which are a different way for programs to query the pixel size of the (corresponding pty of the) window they’re opened in.

I’d like to try and change them to the same values you’d get from this query echo -e "\033[14t". So the process should be:

1. Build Zellij from main and run it (there are some detailed instructions in here but I’m happy to also answer questions if you have any).
2. Perform this query inside a Zellij pane: echo -e "\033[14t"
3. Exit Zellij and enter these values hard-coded into the lines above (the first value in the response after [4; is the y size, the one after it the x.
4. Build Zellij again with these values and see if it solves the issue (make sure to use a pane of the same window and font size, since for the moment the values are hard-coded)

Hoi 👋

Thanks for all your work on Zellij! It’s been a real game-changer coming from using tmux/hyper to handle my multiplexing needs.

Looks like I’m also having this issue in Zellij on iterm2, I’ve taken some screenshots of the suggested actions:

In a Zellij Session:

Out of the session:

If there’s any other testing that can be done to assist in debugging, please feel free to let me know 🙌

Hey @jessebot - really glad you’re happy with Zellij. What you mentioned sounds like a cool use-case, I hope to have more time to put in more cool multiplayer features in the future.

I was unfortunately not able to reproduce this. Using wezterm (I don’t have access to a mac, so couldn’t try with iterm2) with either bare img2sixel or even by cating the log file you attached, which means I’m getting the exact same bytes over the wire, ruling out application versions and the like.

I still want to solve this, so let’s explore this further:

1. Does this happen every time, on every terminal emulator?
2. On startup and window size change, Zellij queries the terminal emulator for a pixel/cell ratio. If for some reason this query wasn’t working properly, it could very much explain this problem (Zellij thinks the image is bigger than it actually is and doesn’t map it properly to the viewport). From within Zellij, if you do echo -e "\033[16t", what do you get? If you quit zellij and do it again (making sure not to change font size or window size) do you get the same thing?