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

[enh]

On Wed, Mar 20, 2024 at 9:38 AM Rob Landley <rob at landley.net> wrote:

> 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.
>

(...but there's a lot of confusion because many modern systems have more
just a symlink to less.)


> > 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
> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20240320/e136ca4f/attachment.htm>