I am definitely waiting for a "modern less replacement" in the same vein as fd, sd, fzf, and the rest of the under-20yo cli crew. I get that "less" is reasonably maintained still.
I think the killer feature for me would be refresh. I get that this can't work for piped input, but I want `git diff` to show in a pager with a refresh button that holds my place. fzf supports both refresh and piped input, so perhaps there's some ideas there that could be leveraged.
I went looking for a 'new' pager a couple years back and settled on this [0]. I've since gone back to `less` since it got annoying jumping between systems and having different pagers, but when I used it it was quite nice.
Didn't know that! I tried it and it doesn't work for me, sadly. Test case: `seq 1 100 | bat --pager=builtin` Result: immediate exit, no output printed at all.
If you want ‘git diff | pager’ to work like that, you’re out of luck. There is no way for the pager to communicate with git or the shell to rerun the command; the pager doesn’t even know what program is on the writing side of its stdin pipe. You would need something like ‘pager --command "git diff"’, where the pager invokes a command producing output. I do agree that it would be nice.
can you give an example of what you mean and how you might expect it to be achieved with a reloaded diff? otherwise `while true; git diff --color=always |less -r; done` gets you most of the way to what you are asking for
Realistically, I will be reviewing a diff, see a hunk I don’t like, change it, and want to see the change back in less. So saving my scroll offset would accomplish my goal. I guess I should add that I want to be able to quit as well?
Like I said, fzf does this. Bind a key to an action that effectively changes the file from stdin to a different command that it runs, while preserving view state.
+1 I actually came here hoping that OP had built a better `less`. Along with refresh, I'd also love to see mouse compatibility (scrolling etc.) and better performance when reading huge files.
Slightly related: I am an Arab who speaks Arabic and reads Arabic and the only place I ever see the unicode character ﷽ is by programmers giving an example of "unicode is too hard".
Perhaps as a graphical element at the beginning of books, too.
It is a part of the Arabic Presentation Forms block which explicitly is for supporting legacy encodings and should not be used.
It’s one code point that’s (in theory) meant to hold the ligature of the whole phrase. As it stands it’s only used as a demonstration of Unicode difficulty.
I wish there was some kind of standard to tell CLI apps what features to expect from the system pager, so they can act accordingly …
Right now, apps can talk to the terminal to check for feature support, but all of that falls apart when the output is piped to a pager. (Do we support inline links? ANSI colors? Sixel support??)
Shameless plug, specifically regarding Sixel support: I needed a pager with better image support than just less -r and made https://github.com/roblillack/lessi
maybe just check TERM? although to be honest--do you even need a pager if your shell/terminal is nice enough?
I rarely pipe to a pager because kitty/fish/tmux support OSC 133 pretty well and I can press one button to go up to the previous command prompt and another button to go back. I can press a few keys to search the scrollback. It all works seamlessly across SSH sessions too if you set it up right.
It's not great but I made a typescript library to wrap pickers recently, such as skim, fuzzel, fzf, dmenu, rofi, etc. Some very similar problems.
Would love if anyone has thoughts or suggestions. It was quick and dirty, and works fine for my use, but I'm not sure where else I could take this, how else I might splice apart the problem, what else would suit it. https://tangled.org/jauntywk.bsky.social/picker-power
I wrote streampager a few years ago to scratch a similar itch. It works well enough for my own uses (and is/was used in library form as the built-in pager for sapling and jj).
I think it still needs some work for more general use which I unfortunately don't have time for at the moment.
How does this compare to less with syntax highlighting? I've been using bat as a pager (bat --paging=always) and it covers most of what I need. Curious what the advantage is for larger files.
The TL;DR doesn’t really say what this new pager offers compared to less; it seems to mostly be a learning project:
> lore supports only a subset of what less does, but in a more intuitive and useful manner for my daily activity. I also find value in understanding it from the ground up, bytes to terminal views, and continuing to refine it as I learn more about what I actually want and need in a terminal pager.
In fact it's not. The name itself mimicks cat, not less. It's a filter that adds annotations to its input, such as syntax highlighting, git diffs and special-char coloring.
Personally I can't find any use for bat: I'm a devote user of vim for editing, and it already does all of this, so why not using it to view files as well? It's satisfying to have the same interface, colors and shortcuts whether you're editing or viewing!
I like it a lot more than `less`, but unfortunately it's always a lot slower when first opening really large files. I'm not sure if it's eagerly loading the whole thing (maybe because that's needed for AST parsing in the case of syntax highlighting, although it happens even on files without highlighting), but there are times I have to swap to `less` still.
If I were to give this post a longer title, it would be "I made a terminal pager because I needed a really good viewport component for my Go TUIs, then realized that a TUI viewport is just a mini terminal pager and I want the same text navigation and manipulation experience everywhere that I encounter long text blocks in my terminal".
I take no issue at all with `less`, it's super powerful and configurable as I call out in the post. I took the functionality I needed, made it a reusable component for Go TUIs, then made a terminal pager in the form of a Go TUI with it.
I am definitely waiting for a "modern less replacement" in the same vein as fd, sd, fzf, and the rest of the under-20yo cli crew. I get that "less" is reasonably maintained still.
I think the killer feature for me would be refresh. I get that this can't work for piped input, but I want `git diff` to show in a pager with a refresh button that holds my place. fzf supports both refresh and piped input, so perhaps there's some ideas there that could be leveraged.
I went looking for a 'new' pager a couple years back and settled on this [0]. I've since gone back to `less` since it got annoying jumping between systems and having different pagers, but when I used it it was quite nice.
[0] https://github.com/walles/moor
I've noticed that subconsciously, I've started to use `bat` for interactive paging, even though that's not its main use case
Bat just uses less internally. And it deliberately breaks less’ handling of ^C, annoyingly.
Bat has an option to use a built-in pager, a Rust crate called minus
Didn't know that! I tried it and it doesn't work for me, sadly. Test case: `seq 1 100 | bat --pager=builtin` Result: immediate exit, no output printed at all.
https://github.com/sharkdp/bat/issues/1053
If you want ‘git diff | pager’ to work like that, you’re out of luck. There is no way for the pager to communicate with git or the shell to rerun the command; the pager doesn’t even know what program is on the writing side of its stdin pipe. You would need something like ‘pager --command "git diff"’, where the pager invokes a command producing output. I do agree that it would be nice.
> holds my place
can you give an example of what you mean and how you might expect it to be achieved with a reloaded diff? otherwise `while true; git diff --color=always |less -r; done` gets you most of the way to what you are asking for
Realistically, I will be reviewing a diff, see a hunk I don’t like, change it, and want to see the change back in less. So saving my scroll offset would accomplish my goal. I guess I should add that I want to be able to quit as well?
Like I said, fzf does this. Bind a key to an action that effectively changes the file from stdin to a different command that it runs, while preserving view state.
+1 I actually came here hoping that OP had built a better `less`. Along with refresh, I'd also love to see mouse compatibility (scrolling etc.) and better performance when reading huge files.
That should be under a less(1) flag, but optional as it can mess piping.
https://github.com/noborus/ov is another pager, in addition to `moor` that somebody else shared.
Slightly related: I am an Arab who speaks Arabic and reads Arabic and the only place I ever see the unicode character ﷽ is by programmers giving an example of "unicode is too hard".
Perhaps as a graphical element at the beginning of books, too.
It is a part of the Arabic Presentation Forms block which explicitly is for supporting legacy encodings and should not be used.
The whole phrase is one character?
It's one codepoint, U+FDFD, with the name "Arabic Ligature Bismillah Ar-Rahman Ar-Raheem".
https://www.compart.com/en/unicode/U+FDFD
It’s one code point that’s (in theory) meant to hold the ligature of the whole phrase. As it stands it’s only used as a demonstration of Unicode difficulty.
﷽ translates to "In the name of Allah, the Most Gracious, the Most Merciful."
But it is indeed just the single character (U+FDFD)
Well-written article!
I wish there was some kind of standard to tell CLI apps what features to expect from the system pager, so they can act accordingly …
Right now, apps can talk to the terminal to check for feature support, but all of that falls apart when the output is piped to a pager. (Do we support inline links? ANSI colors? Sixel support??)
Shameless plug, specifically regarding Sixel support: I needed a pager with better image support than just less -r and made https://github.com/roblillack/lessi
To be pedantic, you mean a standard like IEEE 1003 aka POSIX? (https://pubs.opengroup.org/onlinepubs/9799919799/utilities/m...)
maybe just check TERM? although to be honest--do you even need a pager if your shell/terminal is nice enough?
I rarely pipe to a pager because kitty/fish/tmux support OSC 133 pretty well and I can press one button to go up to the previous command prompt and another button to go back. I can press a few keys to search the scrollback. It all works seamlessly across SSH sessions too if you set it up right.
If I remember correctly, `gum` also provides a pager feature: https://github.com/charmbracelet/gum
TIL about `gum`. I love this and endeavor to integrate it into something sometime. Thank you for mentioning it!
Oh, you will love all of charmbracelet
https://github.com/charmbracelet
It's not great but I made a typescript library to wrap pickers recently, such as skim, fuzzel, fzf, dmenu, rofi, etc. Some very similar problems.
Would love if anyone has thoughts or suggestions. It was quick and dirty, and works fine for my use, but I'm not sure where else I could take this, how else I might splice apart the problem, what else would suit it. https://tangled.org/jauntywk.bsky.social/picker-power
I wrote streampager a few years ago to scratch a similar itch. It works well enough for my own uses (and is/was used in library form as the built-in pager for sapling and jj).
I think it still needs some work for more general use which I unfortunately don't have time for at the moment.
How does this compare to less with syntax highlighting? I've been using bat as a pager (bat --paging=always) and it covers most of what I need. Curious what the advantage is for larger files.
The TL;DR doesn’t really say what this new pager offers compared to less; it seems to mostly be a learning project:
> lore supports only a subset of what less does, but in a more intuitive and useful manner for my daily activity. I also find value in understanding it from the ground up, bytes to terminal views, and continuing to refine it as I learn more about what I actually want and need in a terminal pager.
A Splunk, a Splunk! My kingdom for a Splunk!
(too bad Cisco bought them and made it too expensive).
Also, no "less does more than more and most does more than less" joke?
I really like this post! I think it's the clearest explanation I've seen of the different characteristics of utf-8 strings
I suggest writing an intro which would answer 'why' you made it.
Why wouldn't you?
bat is the king of pagers. https://github.com/sharkdp/bat
Doesn’t it just call `less`?
Yes. It calls the default pager (or whatever you specify).
bat does not look like a pager: https://github.com/sharkdp/bat?tab=readme-ov-file#automatic-...
In fact it's not. The name itself mimicks cat, not less. It's a filter that adds annotations to its input, such as syntax highlighting, git diffs and special-char coloring.
Personally I can't find any use for bat: I'm a devote user of vim for editing, and it already does all of this, so why not using it to view files as well? It's satisfying to have the same interface, colors and shortcuts whether you're editing or viewing!
I use it for previewing files in `fzf` and `lf` (terminal file manager).
I like it a lot more than `less`, but unfortunately it's always a lot slower when first opening really large files. I'm not sure if it's eagerly loading the whole thing (maybe because that's needed for AST parsing in the case of syntax highlighting, although it happens even on files without highlighting), but there are times I have to swap to `less` still.
Was curious but the git link there doesn't load?
From the title I thought it’s about a dead man’s switch.
I thought it was about replicating a mossad supply chain attack.
Also called `vi -`
good work
[flagged]
Author here!
If I were to give this post a longer title, it would be "I made a terminal pager because I needed a really good viewport component for my Go TUIs, then realized that a TUI viewport is just a mini terminal pager and I want the same text navigation and manipulation experience everywhere that I encounter long text blocks in my terminal".
I take no issue at all with `less`, it's super powerful and configurable as I call out in the post. I took the functionality I needed, made it a reusable component for Go TUIs, then made a terminal pager in the form of a Go TUI with it.
"Because I felt like it" is also a perfectly acceptable answer ;-)
Still use Wander everyday <3
[flagged]
For a bubbletea application I'd expect more bubbles and tea there. But still, nice project.