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 _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
