[Toybox] [PATCH] vi: don't exit on ^C or ^D.

[Rob Landley]

On 1/23/20 5:09 PM, David Seikel wrote:
> On 2020-01-23 11:40:19, Rob Landley wrote:
>  
>> My own todo list item for a text editor was to make a generic engine I could
>> implement vi, emacs, nano/edit, and joe (wordstar) keybindings on top of (and
>> MAYBE share plumbing with less and watch).
> 
> Which I did write for you, including sharing plumbing with less.  But
> your inability to read code

Yes yes, you wrote something therefore I was obligated to either take it or do
as much work as you were doing on it promptly. I am a bad person and have ruined
your life. Sorry about that.

Clearly I was mistreating you. It's not like tar was in pending for 5 years
before I got serious about cleaning it up and promoting it, and xzcat's been in
pending since 2013. I haven't even cycled back around to cleaning up bc yet.

It's not just external contributions. Sed was in pending for 6 years before I
started over on it, even though I'd already written one for busybox. I started
mke2fs in 2006 and it's still where I put it down when I left busybox. (I
believe the last time I worked on it was at Ottawa Linux Symposium, which was
last held in 2008.) I'm just NOW seriously trying to finish toysh, a can of
worms I first opened literally 15 years ago:

  https://landley.net/notes-2005.html#07-11-2005

Obviously I can't read my _own_ code, that's gotta be the problem.

Speaking of toysh, I am currently reading my way through the kernel source to
try to figure out why calling pipe2() seems to be removing the cloexec flag from
a COMPLETELY UNRELATED ALREADY EXISTING filehandle, which I found out by
sticking printk(KERN_ERR "call %d %lu %lx\n", (int)task_tgid_vnr(current), nr,
*(rcu_dereference_check_fdtable(current->files,current->files->fdt)->close_on_exec));
in the kernel arch/x86/entry/common.c function do_syscall_64() (to print out the
pid, syscall number, and first 32 close-on-exec bits, including fd 5), because
that's where debugging my "cat <(echo hello)" implementation has taken me. I
couldn't make sense of the results of strace so I reproduced it under qemu and
I'm sticking printk() into the kernel to drill down into what's going on here.
(I still really really hope this is _not_ a kernel bug, but something obscure
I'm doing from userspace that I can stop doing, but we'll see where it lands.)

But sure, my problem is an inability to read code, not a shortage of time/energy
for a project that's not my day job while juggling multiple open source balls, a
family life, and travel. Fine.

Did you know there are _categories_ of cans of worms? "This is a can of worms I
want to open", "This is a can of worms I'm dubious about", "This is a can of
worms I'd rather not open but probably have to", "this is a can of worms I'd
like to figure out how NOT to open", "this is a can of worms I've opened 3 times
already and is now SUCH a mess in my head not knowing where I left off and what
I did or didn't save or what was an avenue I explored and rejected vs a good
idea I hadn't finished implementing that I think I need to start over from
scratch (I am SORRY about dd)"...

Coding is the easy part. Getting the design right is the hard part. That's where
most of the work _is_.

Ahem.

The vi currently in pending started small and simple. Its author is _not_
proposing large changes to lib/ that I haven't had time to examine, and this
command isn't threatening to reach out and consume 5 other commands (as much as
I'd _like_ to share infrastructure I'd kinda want to in the loop on the design
decisions and haven't got spare brain right now), and it works well enough that
Elliott's sent some patches for it which is an endorsement.

That said, I haven't done enough review to render an informed opinion on the new
patch set which proposed changing the infrastructure. (I haven't said no, but
they haven't said "yes this is definitely the way I want to go" yet, so the
patches are kinda sitting there.) A quick glance says the first thing I'd do to
toys/pending/vi.c is refactor the coding style (unsurprising; I tend to order
functions to avoid function prototypes, I'd have the short for () and if () be
on the same line, collate the variable declarations of the same type, etc, which
would _probably_ bring it down under 1000 lines.) But doing that would make it
harder for its original author to work on it (it wouldn't look natural to
_them_), and is thus unnecessary noise until A) they're happy enough with it to
down tools, B) I'm in a position to take at least some of the weight of bug
reports, C) there is an actual benefit to doing so (ala the level of code review
did for tar, one instance of which I documented in
http://landley.net/toybox/cleanup.html#ifconfig back when I thought doing that
would help).

In comparison, before you even wrote yours you insisted it was going to eat sed:

http://lists.landley.net/pipermail/toybox-landley.net/2012-June/005495.html

So the scope of trust you were asking for, for your new infrastructure, was
immediately quite large.

When I tried your external project there were multiple problems, and when I
asked for small pieces (thinking "I need to implement top", "I need to implement
command shell editing", infrastructure I'm sure can be shared with the various
use cases would be a good first step) and you said (replying to a 2012 post in
2014) "that's most of the whole editor":

http://lists.landley.net/pipermail/toybox-landley.net/2014-January/003262.html

Yes, you spent a year getting back to me and blamed me for being slow to react
to you. Meanwhile you were telling _me_ that your external project doing many
things (like joe support) would need a lot of cleaning up:

http://lists.landley.net/pipermail/toybox-landley.net/2014-January/006490.html

When I next reviewed your code (which clearly can't have happened because I
can't read code), it was already 1000 lines longer than the vi implementation I
merged, it modified multiple files in multiple directories, and I had an awful
lot of questions:

  http://lists.landley.net/pipermail/toybox-landley.net/2015-May/007422.html

But yes, this is entirely my fault. I once again apologize, 5 years after I told
you that since it was already clearly an external project and you could just
make a go of it _as_ an external project. It's come back around so you can once
againn insult me, and I can apologize about again. Done. Can we move on?

> On the other hand, "other plans" means converting it to use Lua as the
> glue layer between the C editing functions and the various editor key
> bindings.  Something I'd much rather do anyway, though I recall you
> dropped your initial idea to include Lua in toybox.

No, 11 years ago I thought about implementing toybox _in_ lua:

  http://landley.net/notes-2009.html#18-10-2009

But didn't because it doesn't ship with standard posix bindings (there was an
external add-on library but it wasn't complete) and I worked out you'd need to
install ~7 packages to implement then-busybox in lua. As I explained to you in 2011:

http://lists.landley.net/pipermail/toybox-landley.net/2011-November/004935.html

Perhaps you're confusing me with the other people have tried to bolt lua to
toybox (regardless of license issues)?

  https://github.com/landley/toybox/issues/129

Meanwhile, I have something like 30 half-finished (unposted) FAQ entries. I
meant to get a toybox release out before flying to Tokyo, and didn't, and at
this point I'm unlikely to get one out until after my flight back to Austin
(even though half of that work is just reviewing the git log and writing release
notes). And I'm writing this email instead of debugging toysh in the time I have
until Jeff gets back from his meeting, reviewing a 5 year old issue you're still
bitter about.

Rob