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 (4296c92d7d91b210149ecfb8dd72e487fb747eff) 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

[?25l[?2026l[?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