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