On 3/21/24 16:13, Oliver Webb wrote:
> On Thursday, March 21st, 2024 at 15:53, Rob Landley <r...@landley.net> wrote:
>
>> I note that "more" is from the days of daisy wheel teletypes, and was thus
>> designed to work ok without a tty or interaction through cursor keys (you can
>> export $COLUMNS and $LINES or just let it guess 80x25), and "less" requires a
>> tty and cursor keys. This might make "more" a better fit for on-screen
>> keyboards
>> that don't provide cursor keys. (Or not...)
>
> less supports vi keys (hjkl), and all the keybindings of more. less doesn't
> require
> cursor keys in the same way vi doesn't, it's just how it's more commonly used.
Piping data through more doesn't allocate memory. Piping data through less
continues to allocate memory as data is accumulated. I don't know if there's a
backscroll limit, so I don't know if there's a limit on the amount of memory it
allocates.
>> I would like to have one implementation sharing code. Implementing "less -R"
>> cuts the behavior delta between the two, and having an option to let ctrl-c
>> exit
>> less (instead of just killing the rest of the pipeline) probably gets us
>> close
>> enough we to handwave the rest?
>
> There is less -K and less -E (exit on C-c and exit at EOF respectively),
Good to know.
> so more_main would look something like:
>
> void more_main(void)
> {
> toys.optflags |= FLAG_E|FLAG_K|FLAG_R;
> less_main();
> }
>
> Once we have a good enough less.
We could implement a big thing and have it pretend to be a small simple thing,
yes.
Rob
_______________________________________________
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net
