Tmux issues (OSX?)

Awesome project! Saves me the annoyance of changing windows or resizing things so I can build tex files and view their results side by side.

I found an error working with tmux. When the pdf is rebuilt the pdf will display in pane where tdf was not run. For example, I have my code on the left, tdf on the right, and the pdf might pop up on the left side. This is quickly resolved by a ctrl+L to redraw. (I'd call this less of an inconvenience than changing windows :)

I say might because sometimes tdf reloads the pdf during the build. When this happens, tdf reports that the pdf is broken. I have not gotten this to recover :( But sometimes there is a full crash and the terminal must be reset! (This might be ratatui? But perhaps some error handling could cause to fail more gracefully). I can get logs and try to make a minimum reproducible error if this will help.

_{^{I haven't looked into the code, but it is on the docket. But I also don't know rust >.< This is a cool project, so good motivation to finally learn rust :)}}

So the issue of tdf reporting that the pdf is broken is something I've run into before - it seems to occur when the rendered file is deleted, then re-written. But the latest commit (4296c92) has fixed this (hasn't gotten rid of the error, since it is what's happening - the file isn't there anymore - but it recovers gracefully from it now).

However, I don't think I've run into a crash as of yet - if you'd be able to run a debug version of tdf with the env var RUST_BACKTRACE=1 to get a trace of what's going on when it crashes, that would be very appreciated.

I also don't use tmux, so I'm not quite certain what you mean by it moving to a different pane from where it's run. A video of what you're describing would also be nice :)

So the crash happens if I try to do anything like move a page or search or something.
Forgive my naivity here, but was the backtrace variable supposed to cause report to stderr? All I get is

Error: "SendError(..)"
                                  %

So no flush. Which is always annoying. But it does leave my cli in a broken state
So I redirected (&>) into a crash log. The tail is this

�[39m�[49m�[59m�[0m�[?25l�[?2026l�[2J�[?2026hthread 'main' panicked at /Users/steven/.cargo/git/checkouts/ratatui-d84b601c74cee23d/989490d/src/buffer/buffer.rs:238:13:
index outside of buffer: the area is Rect { x: 0, y: 0, width: 103, height: 53 } but index is (103, 4)
stack backtrace:
   0: _rust_begin_unwind
   1: core::panicking::panic_fmt
   2: ratatui::buffer::buffer::Buffer::index_of
   3: ratatui_image::protocol::iterm2::render
   4: tdf::tui::Tui::render
   5: ratatui::terminal::terminal::Terminal<B>::draw
   6: tokio::runtime::park::CachedParkThread::block_on
   7: tokio::runtime::context::runtime::enter_runtime
   8: tokio::runtime::runtime::Runtime::block_on
   9: tdf::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

With the full backtrace

                                                                                                                                                                thread 'main' panicked at /Users/steven/.cargo/g
it/checkouts/ratatui-d84b601c74cee23d/989490d/src/buffer/buffer.rs:238:13:
index outside of buffer: the area is Rect { x: 0, y: 0, width: 103, height: 53 } but index is (103, 4)
stack backtrace:
   0:        0x102ed6640 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h10df881e66b2a0f1
   1:        0x102eef80c - core::fmt::write::h05de2f6717b74848
   2:        0x102ed3a28 - std::io::Write::write_fmt::hf37a1cf24f4cbdbd
   3:        0x102ed6498 - std::sys_common::backtrace::print::h89bffd8971af9316
   4:        0x102ed765c - std::panicking::default_hook::{{closure}}::h442f9e9fe4d9e33d
   5:        0x102ed7350 - std::panicking::default_hook::hc8669f7c680a9e8b
   6:        0x102ed7f18 - std::panicking::rust_panic_with_hook::h121a570c9e5d2417
   7:        0x102ed7944 - std::panicking::begin_panic_handler::{{closure}}::h402d4a6dc2b420d6
   8:        0x102ed6ac4 - std::sys_common::backtrace::__rust_end_short_backtrace::h549cf2aec16e1bfe
   9:        0x102ed76b4 - _rust_begin_unwind
  10:        0x102f001e8 - core::panicking::panic_fmt::h21ca8b2faf5fea19
  11:        0x102e8b650 - ratatui::buffer::buffer::Buffer::index_of::hc6768588dbfcbbf7
  12:        0x102e47da0 - ratatui_image::protocol::iterm2::render::he1d113c68a62acd9
  13:        0x102e05ee8 - tdf::tui::Tui::render::h081a415793e0992e
  14:        0x102e195ac - ratatui::terminal::terminal::Terminal<B>::draw::h384f4ff7663ccf47
  15:        0x102e1dd6c - tokio::runtime::park::CachedParkThread::block_on::h8f682bafeea2433e
  16:        0x102e24bc4 - tokio::runtime::context::runtime::enter_runtime::h27847ccfc9b19706
  17:        0x102e11760 - tokio::runtime::runtime::Runtime::block_on::h9e80f472e4c2e1bd
  18:        0x102e259ec - tdf::main::h9bff00b93656f48a
  19:        0x102e1b65c - std::sys_common::backtrace::__rust_begin_short_backtrace::hc038a25fbf76ceea
  20:        0x102e26090 - std::rt::lang_start::{{closure}}::hafc673209a0679df
  21:        0x102ecf760 - std::rt::lang_start_internal::h99fbd40a4808c3db
  22:        0x102e25ae0 - _main

I noticed the bad chars after I did the full, sorry. So I went back to do the backtrace with 1 again and this time (after running reset in my term) it did not release. This time the tail of the log is only showing

    Couldn't render a page: Couldn't open document: PDF document is damaged          Rendered: 100%
                                                                                                       %

FWIW, it appears that these are the same even if I run tdf outside tmux.

As for the video, I'll get this to you tomorrow (I promise I'll be back). Just got to finish my submission tonight

Ah, I think I know what's going on: does the name of your document has any non-ascii characters in it? I don't think tdf handles those correctly, so I'll fix that soon.

Oh, sorry - I totally lied. Looks like this issue lies within the image rendering inside iterm2. Would you be able to check if this same pdf works fine with tdf inside kitty or wezterm?

Sorry for late reply.

document has any non-ascii characters in it?

It's called main.tex lol. The title in the PDF is also just ASCII characters

or wezterm?

Actually that's what I use.

Here's a crash that happens when you open tdf and then create a new pane with tmux

I can't seem to recreate the wrong pane render issue but I'll at least show a recompile and workflow gif. At least this can serve as a motivation and why I know at least a dozen researchers who will love this tool and why I myself am willing to put in time and effort. I think you can see how useful this would be with a non-trivial tex document

Basically the wrong pane render was I got the title page on the left side when doing a recompile. FWIW, this happens outside of tmux, so I think only that random wrong pane glitch is actually a tmux issue. It's quite possible if we get the crash when rendering issue solved that it'll reappear.

I put in some time this weekend to look more at the code and learn some of what's going on. Maybe this can be solved with a simple retry loop?

Actually, I think I have an easy test that is likely related to the tmux issue. I was thinking that it was because the effective terminal window size changes and so what if we just resize Wez? First time, it locked up. Second time is this gif. So seems the issue is inconsistent. When the terminal goes blank, I cannot recover. Even ctrl+c is not respected.

tdf doesnt seem to work in tmux entirely, i just end up seeing redlines instead

I didn't see that you have a tmux.conf, does it work if you correct the terminal color settings? This often messes with display

https://github.com/stevenwalton/.dotfiles/blob/master/rc_files/tmux.conf#L13

(fwiw I also tend to do alias tmux='tmux -2')

Ok will look into that thank you

Some tmux issues should be fixed by ratatui-image 4.2.0 https://github.com/benjajaja/ratatui-image/blob/master/CHANGELOG.md#420---2024-12-31-

Hi, I am also trying to figure this out for my tmux. When I run it I get this blank screen in my tmux and when I run it outside I get just a working tdf reader. I am using kitty

I tried it using stevenwaltons tmux conf too.

Would also like to get it working inside the vim terminal as well if at all possible

Perhaps you could update your version of ratatui such that it is version 4.2.0. Other than that I have no idea what to do

tdf's version of ratatui-image (which is a git fork that I'm using while I'm still in the work of getting some changes upstreamed to ratatui itself) is updated all the way to version 4.2.0, so that shouldn't be the issue. Perhaps some of the code I've changed has broken the tmux support? I'm not certain.

I haven't ever tried out tmux, but I can try it out soon to see if I can reproduce the issues y'all are running into here.

tdf's version of ratatui-image (which is a git fork that I'm using while I'm still in the work of getting some changes upstreamed to ratatui itself) is updated all the way to version 4.2.0, so that shouldn't be the issue. Perhaps some of the code I've changed has broken the tmux support? I'm not certain.

I haven't ever tried out tmux, but I can try it out soon to see if I can reproduce the issues y'all are running into here.

Yeah, that would be awesome if you could figure it out! If you could also figure out some way to have it open inside a terminal embedded in vim would also be really nice too, since my main use for this (and a lot of my freinds) would be having a quality pdf reader in the terminal next to them when typing up a latex doc. Happy to help on this issue if there is anything

@Austin4705

I've learned a lot since I made this issue and just so others know, tmux can be quite an annoying thing to deal with (I'm constantly looking for another solution). A lot of programs have multiplexer passthrough options but honestly I don't know enough about this. I could dig around and try to find some of the relevant issues and discussions but tbh I've been quite busy lately.

But for issues like @Austin4705's, I'd actually suggest against tmux. Your terminal emulator should support splitting. If not, I suggest getting another terminal. I'd strongly recommend ghostty, though alacritty, wezterm, and foot (linux + wayland only) are good alternatives. I have a wezterm config in my dotfiles, since you were looking there, but I have switched to ghostty and not planning on going back. The advantage of tmux is when you work on remote machines (something I do frequently) and you need persistent sessions (you don't have to mess with nohup and background sessions and all that fun stuff). But if you're more interested in partitioning your terminal on the machine you're sitting in front of, then tmux is not the right solution. Basically, no need for tmux unless you do a lot of sshing

Fwiw, my usecase is quite similar, as can be seen by the screenshots haha. And this is what I do locally. But sometimes I'm working on a remote document and so that's where the issue really comes from.

Edit: Ops, I noticed you said you use Kitty. Kitty does support splitting (I have a config for that too). Though I'd still recommend giving another terminal emulator a try ;)

I've learned a lot since I made this issue and just so others know, tmux can be quite an annoying thing to deal with (I'm constantly looking for another solution). A lot of programs have multiplexer passthrough options but honestly I don't know enough about this. I could dig around and try to find some of the relevant issues and discussions but tbh I've been quite busy lately.

But for issues like @Austin4705's, I'd actually suggest against tmux. Your terminal emulator should support splitting. If not, I suggest getting another terminal. I'd strongly recommend ghostty, though alacritty, wezterm, and foot (linux + wayland only) are good alternatives. I have a wezterm config in my dotfiles, since you were looking there, but I have switched to ghostty and not planning on going back. The advantage of tmux is when you work on remote machines (something I do frequently) and you need persistent sessions (you don't have to mess with nohup and background sessions and all that fun stuff). But if you're more interested in partitioning your terminal on the machine you're sitting in front of, then tmux is not the right solution. Basically, no need for tmux unless you do a lot of sshing

Fwiw, my usecase is quite similar, as can be seen by the screenshots haha. And this is what I do locally. But sometimes I'm working on a remote document and so that's where the issue really comes from.

Edit: Ops, I noticed you said you use Kitty. Kitty does support splitting (I have a config for that too). Though I'd still recommend giving another terminal emulator a try ;)

Thanks for the in depth reply!
Actually, I think kitty can support splitting natively. The only issue is that I dont know how to resize the splitscreen and it is a bit intrusive to my workflow. Also, my most prefered solution is to have a pdf reader tab inside of nvim, which does not work at the moment. I also have friends that told me they will use this if it works inside vs code temrinal as well.

I am also on mac so those options wont necessaily work I think :(

@ethanuppal

@ethanuppal yes that would be amazing! I have a branch missing_kitty_tmux_escapes, which also includes some other minor performance improvments.

ratatui/ratatui-image#140

@ethanuppal

@ethanuppal hold on that for a second, the branch doesn't work correctly yet

@ethanuppal

@ethanuppal you can test it now with tdf if you want, I completed testing tmux under kitty (kitty), foot (sixel), and wezterm (iterm2). Only wezterm doesn't work correctly when in tmux, but that's some other impossible problem.

@ethanuppal you can test it now with tdf if you want, I completed testing tmux under kitty (kitty), foot (sixel), and wezterm (iterm2). Only wezterm doesn't work correctly when in tmux, but that's some other impossible problem.

I wasn't able to build tdf by replacing the ratatui-image dependency with yours.

Sorry that I've been so quiet on this thread.

tdf doesn't work under kitty + tmux right now because it uses kittage, a crate I wrote for transferring images to kitty over shared memory objects (faster than writing to stdout through ratatui-image). However, kittage doesn't work with tmux.

I tried a lot when I was working on kittage to get it to work with tmux, but it never seemed to function correctly, so I just kinda gave up. But we never really had tmux working correctly anyways (as you can tell by the length of this issue and other related ones), so I don't really think switching to kittage over ratatui-image for kitty stuff really broke anything.

I can add back my attempts to get tmux working to kittage, but they probably won't do anything. I just ran into the same issues as I did here.

@itsjunetime

@itsjunetime found it, the issue is simply too large tmux passthrough sequences. On kitty we are in luck, because the protocol already requires chunking for the image data, so we can do that there: put each "chunk" sequence into its own passthrough.

For sixel and iterm2 we're out of luck though. I had "slicing up the image" on my mind already, for rendering an image partially, e.g. "near screen border when scrolling" and stuff like that. It should be possible to slice the image horizontally at least. For vertical slicing there is a limitation in ratatui's buffer diffing, where right now it could only work for areas that are a multiple of 2 - but this should get fixed at some point as well. My bet is that horizontal slices should have small enough image data to work with tmux.

ratatui/ratatui-image@81636f7

@ethanuppal

@ethanuppal you can try https://github.com/benjajaja/tdf/tree/ratatui-image-kitty-tmux

@benjajaja

@benjajaja I just tried your fixed build in tmux with kitty. xterm-kitty in kitty, tmux-256color in tmux with stock config except for set -g allow-passthrough on. It didnt work and just gave this if you know why

@Austin4705

@Austin4705 that screenshot cannot possibly be from https://github.com/benjajaja/tdf/tree/ratatui-image-kitty-tmux, that error message doesn't exists there, only in main branch of itsjunetime/tdf.

@Austin4705

@Austin4705 sorry, to be clear: it must be that branch of tdf, because main uses some custom code for kitty.

https://github.com/benjajaja/tdf/tree/ratatui-image-kitty-tmux

It works!!!!! Thank you 🚀

@benjajaja

@benjajaja It works, thanks! Sorry I forgot to switch branches when I compiled your version, oops. Nice job noticing that and rlly appreciate u fixing this

@Austin4705

@Austin4705 amazing!

I'll merge the fixes on ratatui-image and cut a release. @itsjunetime should be easy to back-port the fix, or maybe you could also try out how ratatui-image latest version work with tdf and kitty.

Yeah would be great to merge these changes in

If anyone wants to check out #137 and try it out (on mainly kitty but also other platforms) to make sure tmux works, that would be great

Navigation Menu

Repository navigation

Tmux issues (OSX?) #9

11 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Tmux issues (OSX?) #9

Description

Activity

itsjunetime commented on Aug 16, 2024

stevenwalton commented on Aug 16, 2024

itsjunetime commented on Aug 16, 2024

itsjunetime commented on Aug 16, 2024

stevenwalton commented on Aug 17, 2024

stevenwalton commented on Aug 17, 2024

RafayAhmad7548 commented on Sep 24, 2024

stevenwalton commented on Sep 24, 2024

RafayAhmad7548 commented on Oct 3, 2024

benjajaja commented on Dec 31, 2024

Austin4705 commented on Feb 6, 2025

itsjunetime commented on Feb 7, 2025

Austin4705 commented on Feb 7, 2025

stevenwalton commented on Feb 8, 2025

Austin4705 commented on Feb 8, 2025

11 remaining items

benjajaja commented on Jan 29, 2026

benjajaja commented on Jan 29, 2026

benjajaja commented on Jan 29, 2026

ethanuppal commented on Jan 30, 2026

itsjunetime commented on Jan 31, 2026

benjajaja commented on Feb 1, 2026

benjajaja commented on Feb 2, 2026

Austin4705 commented on Feb 2, 2026

benjajaja commented on Feb 3, 2026

benjajaja commented on Feb 3, 2026

ethanuppal commented on Feb 5, 2026

Austin4705 commented on Feb 5, 2026

benjajaja commented on Feb 5, 2026

ethanuppal commented on Feb 8, 2026

itsjunetime commented on Feb 9, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions