[Toybox] [PATCH] more.c: More stuff, down cursor key scrolls down. Also stuff about less

[Rob Landley]

On 3/20/24 00:02, Oliver Webb via Toybox wrote:
> I spotted the more implementation in pending. Looking at it, it's missing quite a lot of stuff, 
> Such as the ability to go back in a file.

More never had the ability to go backwards, less did. Different command.

> It's built in a way where nothing is accumulated, Which 
> means that support for that would require a half-rewrite.

My todo item in more was that it has to wordwrap to the current screen size to
figure out when it's done a line, and that implies UTF8/unicode fontmetrics, and
also implies ANSI escape sequence handling (for at least color changes).

> What does POSIX specify as far as options?

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/more.html

> Looking at the man page, quite a bit. None of which I've
> ever seen used before.
> 
> Looking at the other keybindings GNU more provides which I can implement, There's "=" (prints current
> line number) ":f" (print filename and line), as well as being able to use the down arrow to go down 
> (with the added side effect of any escape key doing so too, not the end of the world, especially
> since we can't scroll up) That are Implemented them in the attached patch.

Again, more and less are not the same command.

> There is also a testing problem. vi.c doesn't do TEST_HOST because it needs a -s option
> to pass in scripts to test with.

Which is an issue I need to figure out how to address. What does a test that
_only_ toybox passes actually prove? (That it hasn't changed since we last
looked at it?)

> less and more are _worse_ since they don't change anything.

They (and vi) care about current terminal size. Automating tests for that
probably involves a PTY wrapper with a pty master side that can do things like
query the current (virtual) cursor position, which I've sometimes sketched out
notes for but not actually tried to write yet. (It's after "get the test suite
running under qemu in mkroot.)

> Manually testing often introduces regressions, so I dunno what the solution is here

I have design ideas. Blogged about them some years ago, I think? (Or maybe wrote
about them in the mailing list web archive, which dreamhost put some rather
large holes in on more than one occasion because dreamhost...)

> This patch improves things for now, but if we are planning on doing a
> future less implementation. 

I have been planning one all along, yes. The crunch_str() stuff I did was a
first pass at general line handling stuff that could be used by less and by
shell line editing and by vi and so on, but people wrote a vi that does not and
never will share code with the rest of those so that's off the table
permanently. I put that on a back burner until I do shell command editing and
history (which needs to know the indentation from the prompt via the ANSI escape
that sends back a current position, but what should it do when the terminal
doesn't respond to that? People can type ahead before the prompt is even written
and the probe reply gets appended to that so it can come in at any point,
there's some redrawing. In bash there's a horrible \[ and \] escape syntax
around "non printing" characters which you can use to manually fudge its
measurement of ANSI escapes, but it still gets it wrong when the previous
command didn't end with a newline ala "echo -n potato" and I want to get it
right...)

Anyway, there's users of this in "top" and in hexedit's ctrl-F input and so on.
Except hexedit's ctrl-f appears to have broken since I wrote it, how nice...

> We could probably merge more into that and make them share a common base either as 2 functions in
> the same file, or just make more a OLDTOY pointing to less like how [ points to [[.

I've done stuff on this and it turns out the two don't share nearly as much
logic as you'd think. A quick grep finds:

https://landley.net/notes-2018.html#10-10-2018

https://landley.net/notes-2017.html#31-12-2017

> less seems moderately easy (Read lines into list, show lines, scroll down and read more lines,
> scroll up and go back in list.)

It seemed easy to me too, until I sat down to try to understand its behavior.

> Especially since we already have vi.c which does almost all the stuff
> less does at it's core, there's a lot of potential code-sharing (To which
> file though, lib/tty.c?).

I have zero input into the vi.c in pending. I was too slow, so it was taken out
of my hands. I pass along changes to it without particularly reviewing them, it
shares no code with any other command in toybox, and trying to clean it up or
promote it has been punted to a post-1.0 item along with implementing "screen"
and similar.

> But I have to ask the question "If it's so easy, why isn't it in toybox yet?" Is it just because
> other TODO items taking up time, or is it because it's harder to implement than it seems.

Because I care about edge cases like ansi escapes and utf8 fontmetrics and
resizing the screen partway through displaying, because I haven't got test suite
infrastructure that can emulate the other half of a PTY yet without which
testing has to be manual, because I wanted multiple things to share
infrastructure (including potentially stuff like "fold")...

Rob