markbt / streampager Goto Github PK

From a user (internal link: https://fburl.com/uqroyr2t):

My terminal is normally about 15 lines tall and eating almost half of this for noncritical information is pretty frustrating.

Perhaps make it configurable and have a default based on terminal height.

I gave https://github.com/dandavison/delta/ a try (for both Git and Mercurial), and I was scratching my head as to why only some of the colors worked.

The culprit seems to be streampager, because when falling back to less, the colors are fine again.

When doing sp file (where file is large enough to need paging), if file is truncated then sp is killed with a SIGBUS. It should probably survive this.

I sometimes do hg st quickly followed by hg <something>. With less, the second hg can be typed while I wait for output from hg st, but streampager eats my input. I don't know how much of an issue this is; perhaps I'll soon get used to waiting for the prompt to appear before I type.

I noticed that the README says that, with -X, "output will be displayed directly to the terminal until either a full screen of input is received, or Space is pressed" (I couldn't get Space to switch to fullscreen mode, btw). I don't know if that would make it hard to support this feature or if the system calls will let you peek and see if the user has pressed Space.

Currently Ctrl-Z doesn't work in fullscreen mode. It should suspend the pager.

I'd like to update the Void Linux streampager package, but we rely on git tags for fetching sources to build

Perhaps the right fix would be avoiding initializing the terminal when we're in the direct mode.

Hello Mark!

While trying to do some blames via xargs, got an abort. See below.

I was using EdenSCM 4.4.2_20210223_123033_737026f39597_1.fb.el_737026f3.

Jun said that he's seen this type of abort, also.

Failure was repeatable.

$ cd fbcode/eden/edenscm && find . -type f -name "*.py"| xargs hg blame
  simpkins 2019-11-01: # Copyright (c) Facebook, Inc. and its affiliates.
thread '<unnamed>' panicked at 'range end index 323 out of range for slice of length 283', third-party/rust/vendor/streampager-0.8.0/src/file.rs:493:26
                        note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
                                                                                                     xargs: hg: exited with status 255; aborting

(Worked around the crash using --pager=off)

The output blinks up for a moment, and then sp exits with status 101. Capturing its stderr with RUST_BACKTRACE=1 shows:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 11, kind: WouldBlock, message: "Resource temporarily unavailable" }

stack backtrace:
   0: failure::backtrace::internal::InternalBacktrace::new::ha5b2d1e22b191585 (0x55d810d8969f)
   1: failure::backtrace::Backtrace::new::he8937a7fff317027 (0x55d810d8985f)
   2: termwiz::render::terminfo::TerminfoRenderer::render_to::h1f07d18ac39d9fe2 (0x55d810d708fb)
   3: <scopeguard::ScopeGuard<T,F,S> as core::ops::drop::Drop>::drop::hd48c53cfe7245430 (0x55d810cab9f7)
   4: sp::display::start::h872c19cf01890326 (0x55d810c7dd4b)
   5: sp::main::hf9503f69d76a8afe (0x55d810c68691)
   6: std::rt::lang_start::{{closure}}::h4bf6a73ded644694 (0x55d810c7a872)
   7: {{closure}} (0x55d810e09792)
             at src/libstd/rt.rs:49
      do_call<closure,i32>
             at src/libstd/panicking.rs:293
   8: __rust_maybe_catch_panic (0x55d810e11299)
             at src/libpanic_unwind/lib.rs:87
   9: try<i32,closure> (0x55d810e0a29c)
             at src/libstd/panicking.rs:272
      catch_unwind<closure,i32>
             at src/libstd/panic.rs:388
      lang_start_internal
             at src/libstd/rt.rs:48
  10: main (0x55d810c6d621)
  11: __libc_start_main (0x7f104c826f32)
  12: _start (0x55d810c6122d)
  13: <unknown> (0x0)', src/libcore/result.rs:997:5

This error is coming out of termwiz, so maybe its a bug there? It looks like its failing with EAGAIN, presumably while writing to a non-blocking terminal fd. (cc @wez)

This is on Fedora 30, stable Rust.

sp seems to consume all input endlessly and buffer it all in memory. If the input is literally or effectively endless, then this means walking away from the machine for a while will result in something getting oom-killed.

Maybe there should be a (large) upper bound on how much input gets buffered ahead of what's getting displayed.

I don't know why, but I quite often press / because I think I'm going to search for something, but then I change my mind and don't actually need to search. I guess I've gotten used from less to be able to cancel the search by pressing Ctrl+C. I've tried the same many tens of times with streampager without my muscle memory adapting yet (to <enter> followed by<esc>, I guess?).

When scrolling in the VSCode terminal, the screen seems to be shifted by x: -1 temporarily, making it look flaky. This seems to be related to VSCode drawing the cursor at width + 1 column.

If the cursor is made visible then it is no longer flaky:

less remembers the last thing you searched for so you can just press "n" to search for it again next time. It would be nice to have the same feature in streampager.

This may end up being a termwiz bug...

It looks like it reads twenty-something lines and stops; looks like we're blocked in read:

(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00007fff6a223ef2 libsystem_kernel.dylib`read + 10
    frame #1: 0x000000010ddce523 sp`_$LT$termwiz..terminal..unix..UnixTerminal$u20$as$u20$termwiz..terminal..Terminal$GT$::poll_input::h67d2894f39979c8d + 819
    frame #2: 0x000000010dd0419b sp`sp::event::EventStream::get::h3859247ddb8f6064 + 635
    frame #3: 0x000000010dcdc443 sp`sp::display::start::hd7cd8f6d1e4cc3a8 + 3139
    frame #4: 0x000000010dcc6897 sp`sp::main::ha85757a29d4d2a6d + 5991
    frame #5: 0x000000010dcd8c16 sp`std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::h3afe26cb7fcbb116 + 6
    frame #6: 0x000000010de63788 sp`do_call<closure,i32> [inlined] {{closure}} at rt.rs:49:12 [opt]
    frame #7: 0x000000010de6377c sp`do_call<closure,i32> at panicking.rs:293 [opt]
    frame #8: 0x000000010de6a7bf sp`__rust_maybe_catch_panic at lib.rs:87:7 [opt]
    frame #9: 0x000000010de641ae sp`lang_start_internal [inlined] try<i32,closure> at panicking.rs:272:12 [opt]
    frame #10: 0x000000010de6417b sp`lang_start_internal [inlined] catch_unwind<closure,i32> at panic.rs:388 [opt]
    frame #11: 0x000000010de6417b sp`lang_start_internal at rt.rs:48 [opt]
    frame #12: 0x000000010dccb7b9 sp`main + 41
    frame #13: 0x00007fff6a0ed3d5 libdyld.dylib`start + 1
    frame #14: 0x00007fff6a0ed3d5 libdyld.dylib`start + 1

Possibly related to wez/wezterm@cc0d2e5

First of all, thanks for making streampager, it's really neat!

IMO, streampager looks great on a terminal with a light background and pretty bad on a terminal with a dark background. (See below for screenshots)

I'm thinking of implementing a much more simplistic version of #56 in the form of a dark theme. I am thinking of a theme config with possible values light, dark, and maybe auto. This would likely work for me as a replacement for #56, but could also comfortably coexist with the more elaborate configuration suggested in #56.

My current plan for the dark theme would be to have the status bar be white text on a dark-grey background instead of the current black-on-silver. This might change as I try differnet things. I'd also want the dark theme to be readable even on a terminal with a light background (if not necessarily beautiful).

The auto theme, if it is desired, would use something like https://github.com/dalance/termbg to try to pick the theme automatically.

Current theme (would be light):

(The bar looks even lighter in the default xterm theme)

On dark background, the light bar is somewhat distracting.

First pass at dark theme (normal color on dark grey option)

The dark theme on light background doesn't look as good as light theme, but still OK. The user should never see it.

TODO: Show black on blue

When paging a logfile or other append-only file, it would be nice if it noticed that there was new content and displayed it. At the moment it only shows the original extent of the file.

Just log the idea while I encounter it (again). When running git log -p I sometimes find the change I want and wanted to get back to the commit hash. It would be nice to have some sort of "sticky header" so it looks like:

commit deadbeef (sticky header level 1)
diff --git a/filename... (sticky header level 2)
(scroll-able text)

I don't know how to express it exactly. Potentially we can use some kind of ANSI sequences to define "header 1", "header 2" etc that are otherwise no-ops? I'm no expert on ANSI sequences. But if we define it here, I'm interested in implementing it except others beat me on it.

EDIT: Probably should try the new "discussions" GitHub feature for this.

When running in tmux, a simple echo foo | sp (and quitting it) will make the cursor disappear for me. I don't know enough about terminal emulators to guess if it's just that the background color (normally gray for me) is lost or something else. Let me know if it doesn't reproduce for you. I don't know what other details about my environment may be relevant.

Reproduce:

$ cat test.py
print("\x1b]8;;{link}\x1b\\{title}\x1b]8;;\x1b\\".format(link="http://example.com/", title="example"))

$ python test.py

$ python test.py | sp

$ python test.py | less -r

For example:

$ echo -e "\e]8;;http://www.github.com/markbt/streampager/\astreampager\e]8;;\a" | sp
<1B>]8;;http://www.github.com/markbt/streampager/<07>streampager<1B>]8;;<07>

In less, I have bound D to go to the next line starting with ^diff and C to go to the next line starting with ^commit. This makes browsing git output quite nice. I think streampager can't do this out of the box yet, but it prboably would be easy to add.

I often use my mouse to copy-paste chunks of terminal output, and sometimes overshoot (especially since streampager scrolls page-by-page instead of line-by-line like I'm used to), so I scroll back up to re-adjust. In streampager, this causes my selection to be lost and I have to start again. This is not a problem outside of streampager.

It'd be really cool if it was possible to customize the style of the ruler bar in streampager's configuration. Changing background/foreground colors would be a good start, perhaps extended terminal attributes like underline/bold/italic could also be supported.

Currently the bar's default style is hardcoded with AnsiColor::Silver as the background and AnsiColor::Black as the foreground. In a lot of dark terminal themes, that silver color is very bright and stands out significantly compared to, say, code with syntax highlighting.

edit: just noticed #47, which mentions color customization as well. It sounds like a config DSL system has already been mostly sorted out in the process of supporting custom keymaps.

Considerations:

• Colors should ideally support traditional indexed colors as well as "true color", perhaps with fallback - i.e. like termwiz::color::ColorAttribute
• Support for extended attributes could be modeled using termwiz::cell::CellAttributes

Alternatively, something as simple as this in the existing TOML config could be fine to begin with:

[ruler.style.normal]
background = "#555555"
foreground = "15"

[ruler.style.information]
# ...

When @markbt and I saw each other and he showed me streampager, we talked about how the current keyboard shortcuts don't play nice with certain keyboard layouts like AZERTY.

I'm opening this issue not because I expect anyone else to put in the work but to gauge interest and get opinions about implementation in case I ever get the free time needed to add this feature.

Thanks!