bat
bat copied to clipboard
Discussion: a builtin pager for 'bat'
Let's use this ticket to discuss some ideas and possible upsides/downsides of writing our own custom pager library that we could use instead of calling an external $PAGER
process (or, essentially, less
).
A few advantages if we would use a builtin pager in bat
:
- Have one consistent pager experience across all operating systems. No need to call external programs that might not be available. No special handling / bug fixing for different versions of
less
. Consistent "quit if one screen" handling, and much more (#860, #1000, #717, #710, #681, #520, #415, #312, #271, #519, #376, #887, #943, #838, …) - Handling of terminal resize events. This would be my personal main motivation. (#294, #322, #921, #1009)
- Open editor with a key press (#358, #464, #528, #697, #1051, #1607)
- Possibility to always draw the header at the top of the screen, even when scrolling down (#908)
- Builtin
--follow
support (#457, #808) - Special handling for multiple files? (press 'n' to go to the next file)
- Error handling: we could print errors/warnings in the footer of the pager, instead of in the background (#946)
- Better 'tab' handling (#980, #894)
- Handling of ANSI hyperlinks (#961)
- Reload the displayed file with a keypress.
- Disable style components via keypress. For example: switch off the side bar with a keypress - for easy copy&paste.
- Properly handle search with wrapping enabled. Search is currently broken for words being wrapped (#1475)
General advantages of a "pager" as a library (not just for bat
):
- Make everything easily configurable: custom header and footer messages, keybindings
- Bidirectional communication: send events like "terminal resize" or key presses back to the main application to trigger a redraw or other actions.
The obvious downsides are:
- this will be a lot of work :smile:
- I'm sure there will be TONS of bug reports regarding obscure terminal emulators and operating systems where things are not working as expected - which results in even more work.
less
comes with 36 years(!!) of experience.
One way to circumvent the second point would be to make this an opt-in feature, at least in the beginning.
I have actually started to implement a really simple cross-platform pager-as-a-library like this in a private repository. The first results look promising :smile:
I'd be happy to hear about your thoughts and ideas!
I'm 100% in support for all the advantages this would provide.
The obvious downsides are:
- this will be a lot of work :smile:
It would be, but the payoff would be amazing. All those useful features would make bat
even better than it currently is.
One way to circumvent the [volume of bug reports] would be to make this an opt-in feature, at least in the beginning.
I did some brainstorming on my own about this a while back, and I came to the same conclusion. Making it an opt-in flag (--pager=pager-lib-name
) would be a better user experience compared to suddenly changing the pager they use. It should also help reduce the potential for duplicate issues, since not everybody would be experiencing them at the same time.
I have actually started to implement a really simple cross-platform pager-as-a-library like this in a private repository. The first results look promising :smile:
That looks great! I'd be happy to help contribute to it when you feel that it's ready for more contributors :)
I'd be happy to hear about your thoughts and ideas!
Scroll anchoring. When you resize the terminal, having your scroll position jump up or down because of soft-wrapped lines is a frustrating experience. Passing metadata along with each line that defines an anchor could help the pager automatically adjust the scroll position to the new location of the previous anchor.
Wow. I just came across bat the other day and fell in love with the beauty of it. Everything mentioned would make bat a leader in the paging category. Thanks for your passion and hard work
The addition of vim color schemes would be great
I'd also like to see this becoming a printer-friendly solution - not only the on-screen anchor, but per-printed-page anchors (header and footer).
"pager" as a library
A lot of tools could be better with a good library for this. man
(and things like git help
that invoke man
) doesn't support terminal resizing properly either.
Is it an option to simply make the pager a separate program, and have bat recommend using it? That way Unix philosophy is followed more closely.
@metov I'm not very picky and as long as it obeys my export PAGER='/usr/bin/less -iR'
so I don't have to manually shove | less -iR
after every invocation or wrap it in a shell function, I'd like that. but the proposal does make good points for why to have a built-in one.
Found minus and wanted to share
One more thing, I found more
more useful compared to less
since it provide a feature to stop between page breaks (I saw ^L
) for RFC texts, maybe it would be good to support it?
more /usr/share/doc/rfc/txt/rfc6902.txt
vs less -z56 /usr/share/doc/rfc/txt/rfc6902.txt
(I need to manually specify window scrolling size to make it scroll better).
Found minus and wanted to share
It has a C-l
shortcut for togging line numbers, but it shows them quite differently.
Command | Line numbers off | Line numbers on |
---|---|---|
bat -f less-rs.rs | less-rs /dev/stdin |
![]() |
![]() |
bat --pager="less-rs /dev/stdin" -f less-rs.rs |
![]() |
![]() |
bat --pager="less-rs /dev/stdin" -f less-rs.rs --terminal-width=$(($COLUMNS - 4)) |
![]() |
![]() |
bat --pager="less-rs /dev/stdin" -fp less-rs.rs |
![]() |
![]() |
less-rs less-rs.rs |
![]() |
![]() |
minus
has a setting for never/always displaying line numbers (disabling the shortcut), but that's more like a workaround. There might be a way to change the line number display format.
how to use above command on macOS.
bat --pager="less-rs /dev/stdin" -f less-rs.rs --terminal-width=$(($COLUMNS - 4)) >>> should i configure this in any file or run directly in cli once. i tried direct cli rub but getting error. Can someone help please
As the list keeps growing - would you mind publishing your effort https://github.com/sharkdp/bat/issues/1053#issue-631960732, behind an experimental flag?
Unless it raises the binary size too much for "just a wish" that is fully experimentally working.
As the list keeps growing - would you mind publishing your effort #1053 (comment), behind an experimental flag?
Sure - why not. I just "polished" it a little bit, but note that this is not much more than a quick & dirty proof of concept:
https://github.com/sharkdp/riffle
Instead of properly integrating this into bat
as a library, the demo executable currently runs bat
internally (on each terminal resize event) and captures its output.
What it can do:
- [x] Implements most basic input events (up, down, page up, page down, mouse scrolling, quit)
- [x] keeps header and footer fixed at top/bottom of the screen (I noticed that this only makes sense if we display a single file)
- [x] properly redraw on terminal resize (has problems when not at the top of the file, due to wrapping of lines)
- [x] open
$EDITOR
by pressinge
- [x] toggle sidebar by pressing
n
- [x] toggle wrapping by pressing
w
What it can not do:
- [ ] Display multiple files (easy to integrate, but clashes with the 'fix header at the top' feature)
- [ ] Properly handle terminal resize events when wrapping is enabled (see above)
- [ ] every other feature listed in the top post
- [ ] All other typical pager features:
- [ ] searching
- [ ] "quit if one screen"
If someone on Linux/amd64 wants to try this out without compiling: bat-riffle.zip
Screencast: https://asciinema.org/a/YhN35zGJxbnODvbDeXxTEDPG6 (note that I am resizing my terminal window in the last few seconds. Asciinema doesn't really show the full effect here.
Before we go further with this, we should probably come up with a list of requirements and also a draft for the design of this new pager library. I'm not sure if the current callback-based implementation is the best way to proceed. We should also carefully check if one of the already available libraries (e.g. https://crates.io/crates/minus) would be suitable for our needs.
If someone on Linux/amd64 wants to try this out without compiling: bat-riffle.zip
I am not sure what did I do wrong
$ bat-riffle ~/Documents/ISO_Next_Group-after-Shift.sh
bat-riffle: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by bat)
bat-riffle: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by bat)
$ uname -a
Linux h 5.13.0-28-generic #31~20.04.1-Ubuntu SMP Wed Jan 19 14:08:10 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
... but maybe:
$ ldd --version
ldd (Ubuntu GLIBC 2.31-0ubuntu9.2) 2.31
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
That's from Ubuntu 20.04
While we're at it, the possibility to use two columns would be sweet ;-P
e.g.:
- one column shows lines 1-30
- second column shows lines 30-59
- when you scroll, both scroll
😍
Fwiw, nu
community is also working on a (structured) pager - https://github.com/nushell/nushell/pull/6984
Honestly I wish they did more to generalize it, afaict it should work for any structured data/tree data, not necessarily nu
objects