Tmux issues (OSX?)

[stevenwalton]

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 :)}}

[itsjunetime]

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 :)

[stevenwalton]

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

[itsjunetime]

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.

[itsjunetime]

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?

[stevenwalton]

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?

[stevenwalton]

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.

[RafayAhmad7548]

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

[stevenwalton]

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')

[RafayAhmad7548]

Ok will look into that thank you

[benjajaja]

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-

[Austin4705]

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

[itsjunetime]

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.

[Austin4705]

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

[stevenwalton]

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 ;)