On Wed, Mar 20, 2024 at 9:38 AM Rob Landley <[email protected]> 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 > [email protected] > http://lists.landley.net/listinfo.cgi/toybox-landley.net >
_______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
