[Toybox] [CLEANUP][watch.c]

Rob Landley rob at landley.net
Tue Aug 21 10:26:41 PDT 2018


On 08/20/2018 02:39 PM, enh wrote:
> speaking of terminal_size, is there a reason it doesn't call terminal_probesize
> if the ioctl fails? it seems like terminal_probesize is only used in top, in
> response to a signal (presumably for SIGWINCH). whereas terminal_size is used in
> all kinds of places, but never falling back to probing. even in hexedit.c, which
> does call scan_key (which is where the other half of terminal_probesize
> currently lives).

hexedit is the command I used to initially develop the not-curses logic. It's
only using the early stuff because I haven't gone back to add features I hadn't
developed yet. I developed scan_key_getsize() while making top and iotop.

On the one hand I should go back and fix that, on the other it's doing the
"cannonical" 16 byte per line hex+ascii format ala hexdump -C and I'm not sure
how width would usefully change that other than maybe truncating the display to
avoid wordwrap? (Height could usefully change.)

I do have hexedit todo items but they're post-1.0 and involve adding the ability
to insert or remove bytes (right now it's mmaped, that's a bit awkward and
potentially really expensive on huge files, and you don't want to do it
accidentally because that'll corrupt the heck out of formats like ELF), and
adding "cursor over into the text part on the right and let you type letters"...

I'd post my todo lists, but they're scattered over a dozen files I need to
collate, and not written to make sense to anybody but me. And the ones I haven't
done yet tend to have pending design issues I want to work through, or some
research I need to do first...

> would it make more sense to have the scan_key "scratch" buffer be a hidden
> buffer in lib?

Making more things use scan_key_getsize() is a big item on my todo list, yes.

Keep in mind it needs to consume asynchronous input from stdin when it does
that, at an arbitrary delay (other data could already be queued up on stdin with
the probe appended after, and a probe result over an ssh session on a marginal
phone connection can come in 3 seconds later, which is my life using my netbook
with phone tethering in milwaukee's brick buildings).

But I switched from a day job at a failing startup that ate all my time to a day
job in a cubicle at a fortune 500 company that eats all my energy. (I got home
last night and fell asleep at 9, got up for a couple hours around midnight, and
was back in bed by 2am. I didn't even hit send on the email I composed until I
noticed this morning. Cubicles suck the life out of me, always have. You
wouldn't think you could combine isolation with lack of privacy but they found a
way...) I get a little work in on an evening and sometimes get some on the
weekends, but the last two weekends were mostly spent on mkroot, not toybox.
(And really they were spent on musl-cross-make.)

Anyway, yes watch should use scan_key_getsize(), and do several other things
it's not currently doing (progressive display, controlled wordwrapping, honoring
the display time with kill/restart...). I'm about 1/3 of the way through a
rewrite making watch work right by my standards, and there are still some scope
issues I want to work out (should it parse ansi color sequences to get the
wrapping right, or display all low ascii as reverse video like debian's watch
does? If it -does_ parse the escape sequences should I try to genericize the
sequence recognition code in ). I should almost certainly do it as multiple
passes adding things like that later and getting the basics working properly
first, but I should also move as much of this as I can to generic infrastructure
and come up with a better template for new commands using this. (This is what
toys/example/demo_scankey.c was for, but it doesn't handle wordwrapping.)

My plan was to do a demo_cmdline.c for command line editing (it's one of the
many unfinished things in my tree), which involves cursoring around within text
and inserting with dynamic wordwrap. And then I could do a simple text editor by
stacking those (hence lib/linestack.c). And then a watch that _properly_ parses
the output and interprets "cursor up" and "jump to location" and everything is
halfway to implementing "screen"...

Alas, 5 years after my 2013 video toybox is still just a hobby, and ever since I
got married and bought a Real House I haven't been able to do the "work for 6
months, take 6 months off to do open source" thing I used to. (I'm very grateful
to my patreon supporters, thankful for the encouragement, and if I didn't have
any living expenses and ignoring taxes that would only take about 35 years for
that to pay off the home equity loan I took out to stay an extra year at SEI to
try to "make it work".)

Adulting sucks.

Lunchtime over, back on my head...

Rob


More information about the Toybox mailing list