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

[Jarno Mäkipää]

I looked into ex commands little bit more, All the edits seem to be
line based or correct me if im wrong? So ex commands dont naturally
provide way to test the difficult cases such as: delete until start of
word at current cursor position in last line of document when we are
sitting in this zalgo text separated by few invalid utf8 bytes.... so
atleast we need to extend it, so that every visual command has toy_ex
substitute...


On Sat, Jan 18, 2020 at 8:15 AM Rob Landley <rob at landley.net> wrote:
>
> On 1/17/20 11:36 AM, enh via Toybox wrote:
> > alternatively we could say "we don't actually care about ex, but do
> > want to have a 'scriptable vi'" and have a mode where toybox vi takes
> > commands that are just vi commands, not ex commands. that's better in
> > terms of smaller code, even if it's then a toybox "exclusive".
>
> If ex is basically free and there's no reason _not_ to have it, fine. I just
> don't know any demand for it as its own thing.
>
> > either sounds like a good idea to me (with me personally leaning
> > towards "just take vi commands until/unless there's a proven need to
> > actually be ex compatible, since our only known use case is testing
> > vi"), but sounds like a decision for rob.
>
> Accidentally typing the key so that vi claims it isn't in "visual" mode anymore
> annoys me, and then I need to undo it. (I think hit escape and i a lot until it
> stops?)
>
> That's pretty much my entire interaction with ex. I vaguely recall Al Viro uses
> it sometimes instead of sed.
>
> Rob
>
> > /me wonders how vim testing works. anyone know?

I dont know what Bram uses, but both neovim and vis seem to use lua on
their testing

https://github.com/neovim/neovim/tree/master/test
https://github.com/martanne/vis-test/tree/46a2b9991ff3faf47b02dfe9b37ffb0efe354b3d



>
> I made a "txpect" command for shell testing, might want to look at that. Note
> that zero length input is "read a line and discard it"... oh here:
>
> > # Prompt changes for root/normal user
> > [ $(id -u) -eq 0 ] && P='# ' || P='$ '
> > # run sufficiently isolated shell child process to get predictable results
> > SH="env -i PATH=${PATH at Q} PS1='\\$ ' $SH --noediting --noprofile --norc -is"
>
> The @Q syntax is a horrible obscure bash thing that gives you a quoted string
> version of the shell variable contents. So the above sets two environment variables:
>
> $P = whatever your default shell prompt should be, given whether you're root or not.
>
> $SH = a shell command line to run to tell the shell NOT to read /etc/profile and
> friends, marshall over the host $PATH, use a predictable prompt, and behave in
> an interactive manner even though stdin isn't a tty.
>
> Then the tests:
>
> > txpect "prompt and exit" "$SH" "E$P" "Iexit\n" X0
>
> Run "$SH", then read the $P prompt from stderr, then write "exit\n" to stdin,
> then expect it to exit with rc 0.
>
> Yes, the prompt is on stderr, not stdout. Because posix says so. I was surprised
> too, and had to change it.
>
> And yes, if this has a 2 byte string it will read 2 bytes from the source in
> question and match it, and NOT read any other pending input yet.
>
> > txpect "prompt and echo" "$SH" "E$P" "Iecho hello\n" "Ohello"$'\n' "E$P" X0
>
> Run $SH, read the prompt from stderr, send "echo hello\n" to stdin, read
> "hello\n" from stdout (note: $'\n' is another bash syntax, says echo -e the
> contents of the '' so that turns the \n into ascii 10, which none of these
> strings are doing for you), read the prompt, exit 0.
>
> > txpect "redirect err" "$SH" "E$P" "Iecho > /dev/full\n" "E" "E$P" X0
>
> Run $SH, read prompt, write "echo > /dev/fnull\n" to stdin, read a line from
> stderr and discard it, read the prompt from stderr again, exit with 0 (note: X
> closes the program's stdin so it should exit at that point).
>
> Note "E" by itself reads a full line (until newline) and then there's more data
> after that, which we match specifically. O by itself should also do that.
>
> Rob

Need to look into this.