[Toybox] [PATCH] microcom: simple menu, new "paste file" functionality.

[enh]

On Sat, Oct 28, 2023 at 12:29 AM Rob Landley <rob at landley.net> wrote:
>
> On 10/25/23 19:48, enh via Toybox wrote:
> > Rather than take up yet another key for the new functionality, I've moved
> > everything to a menu, similar to the one in telnet. It's not amazing,
> > but it's the least code I could get away with, and it's good enough for
> > now, and it leaves us in a better place if we need to add more stuff
> > (such as xmodem, say).
> >
> > But this is enough to let me stop using minicom and get back to toybox
> > microcom for today!
>
> What I always did was "toybox uuencode target_filename < local_file | xclip
> -selection clipboard" and then run uudecode at the far end and right
> click->paste it into the relevant xterm window. I hadn't noticed a size limit...

yeah, so recently i had one group ask for xmodem and another group who
just wanted to use base64. the latter was the thing i could do in half
an hour :-)

(others had no idea how to transfer a file over serial at all. no-one
came up with your solution _that i know of_ but maybe this is what the
people who complained that "doing the paste myself is flaky"?)

> There was discussion of a CTRL() macro in context of vi, but I don't see where
> it was applied to toys.h or lib/lib.h? Ah, it's in glibc's sys/ttydefaults.h
> which is included from termios.h... but not in the NDK build, or in the musl
> build. It _only_ leaks in the glibc build.

ah, oops. i did check that everyone (including macOS) _has_
<sys/ttydefaults.h>, but i didn't check that it was getting
[transitively] included everywhere.

> The macro's actually a bit non-obvious to me because CTRL(A) and CTRL(a) seem
> like they should produce different results? Ah, and they want CTRL('A').

yeah, if we did our own macro i'd suggest `#define whatever(ch) (((ch)
^ 0x20) - '@')` to avoid that. there doesn't seem to be a strong
consensus about whether it's more natural to say A or a, so may as
well make both work.

> What was wrong with 'A'-64 again?

that's a variant i _haven't_ seen yet. 'A'-'@' seems more common, but
it's not as readable to n00bs.

> You want "p) paste file" instead of "f) send file"? (Paste-but-not-clipboard has
> more mnemonic weight than File?)

having used this for a week, i intend to send you another patch that
changes 'e' for exit to 'q' for quit because that's been annoying, but
i don't have a strong opinion on 'p'. i went with that because it was
the "more direct" of minicom's _two_ ways to send a file as "ascii"
(terminology i disliked for obvious reasons).

it sounds like the cool kids use https://github.com/tio/tio these
days, and https://github.com/tio/tio#32-key-commands shows that it
doesn't have an equivalent of this functionality anyway.

> The read(1) loop is similar to the loop in lib/passwd.c:read_password() and I
> should probably factor it out.

yeah, and similar to vi and hexedit. this was the minimum i needed
right now, though, and i thought you'd have strong opinions on what
exactly to factor out anyway, given that the shell is going to need
something readline-like.

> You only accept DELETE not BACKSPACE to shorten
> the input line?

yeah, and i didn't do arrow keys or home/end or anything else; nor did
i deal with "what happens when you have more input than fits on one
line?" ... in the week i've used this, _tab_ (for file completion) was
the thing i would have actually liked, but not enough to warrant
implementing it, and especially not before the inevitable [but hard to
predict timing of] factoring out!

> You have a progress indicator instead of letting the other end do that. (How big
> are the files you're sending?)

well, i'm using this for `base64 -d -i > file` so the other side isn't
going to help me here. (and a quick glance at the xmodem docs suggests
that one of the limitations of that protocol is that it doesn't
include file size, so even there i think the _sender_ is going to have
to do the work.)

given that the only use i see for this is "your board can't even do
adb yet", the likelihood [for me] is that i'm having to send static
binaries. after seeing how long a 20MiB [well, ~10MiB, but base64
bloats it up] binary took (two meetings + cooking and eating a meal),
i did make an effort to trim my binary down to just what i actually
needed to iterate on, but even so it was a couple of MiB each time.
"long enough that i favored one of minicom's two alternatives for this
functionality based on the fact that it showed me progress, but not
long enough that i bothered to implement a countdown/ETA".

> Rob