scroll(1) – pager #44
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What should our pager program look like?
I have a particularly bad one in my source tree. It was less useful once I'd figured out I could scroll my xterms but nowadays I just use less(1).
"Good pager" is a very subjective judgement. I like both Plan 9's p(1) and [I forgot]'s bat(1) though they're both polar opposites. Maybe we should have one that's nearly featureless and one with the kitchen sink, or some sort of way to choose baroque or barren depending on mood.
What do you think of
scroll(1)as a name?pagerto `scroll(1)` – pagerWhat features should scroll(1) have?
jkfor single-line scrolling, PgUp/PgDn for paging)?Definitely.
I don’t think this is in scope for the tool.
I think it should have this.
I will think more on these two.
Scrollback would be cumbersome in cooked mode.
I don't think search should be part of the pager. I think we should make a searching utility and make the pager pipe through that tool instead. This can also be how we implement syntax highlighting.
What if we had a pager/text editor combo? that way we wouldn’t be implementing redundant features
You both read from and write to scrolls.
I think a very light pager would be useful in addition to a (necessarily) slightly heavier editor. We could have two editors - pg(1) (operating in cooked mode using stdio.h) and scroll(1) (operating in raw mode, possibly using curses.h).
My p(1) implementation is a bare minimum pager operating in cooked mode based on Plan 9's utility of the same name. It operates in a loop, printing some lines from /dev/stdin and watching for a newline from /dev/tty before continuing. This would be the core functionality accomplished by pg(1).
The user could enter a newline to page the default amount of lines (22 - this is from Plan 9 and in my experience seems to be a nice default, leaving room to see the current and previous prompts for /dev/tty input on even a very small 24-row terminal window - or whatever the user specifies with the
-doption) or enter an integer value to see only a certain amount of lines past what's been shown.A reverse paging buffer would be very welcome for terminal emulators that don't support scrolling (like many kernel framebuffers) but not necessarily welcome on extremely low-memory systems on which large documents are being paged, so reverse paging can be optional (
-r) and limited if necessary (with-bspecifying a number of bytes on extremely constrained systems and-lspecifying a number of lines on systems only somewhat constrained). Then at the /dev/tty read the user could specify a negative integer value to page backwards.Then at the prompt the user could also change options relating to the running pg(1) instance. I think this is important because on especially constrained systems it might be pertinent to adjust - even coarsely - how much memory is used by the pager, and it's a hassle to restart a pager halfway through paging a very large file. So typing
set default_scroll 47would do just that. This isn't a feature I'd expect from a minimal pager and one I'm not suggesting without considering code complexity - I think it's important and implementation wouldn't be hard or too ineligant.So for pg(1) I'm imagining
Usage: pg (-r (-b [bytes])|(-l [lines])) (-d [lines]).-renables a reverse-scrolling buffer, with the optional-bor-lindicating a maximum size for the buffer in bytes or lines respectively.-dchanges the default amount of lines scrolled.