[Toybox] [PATCH] vi.c: Backspace to merge lines when at beginning, get_endline is no more, cleanup

[Oliver Webb]

(Sorry this took so long to respond to, the email sat in my drafts as I got preoccupied with other stuff)
On Friday, March 8th, 2024 at 02:47, Jarno Mäkipää <jmakip87 at gmail.com> wrote:
> if you want backspace to jump into previous line, you should not call
> ex commands dispatcher in middle of normal mode.

run_vi_cmd() is the vi command dispatcher (hjkl, gg/G, i/I/a/A, standard normal mode stuff).
And run_ex_cmd() is the ex command dispatcher (:s///g, :g//, :w, :q!). This patch calls the 
vi command one, not the ex one.

I don't enjoy calling either whenever unnecessary, I only so do when I can't get the things
run_vi_cmd() is multiplexing to work on their own. vi_join doesn't work and I don't know
why, I'll have to re-read run_vi_cmd() eventually and figure out why things it multiplex
break on direct calls

I'm not terribly familiar with how the buffer management of vi.c works, My main interest
has always been to get a small set of ex commands in, along with fixing whatever segfaults/
lack of functionality I find along the way. I found the run_vi_cmd infrastructure and assumed
I could build off that for ex commands instead of rewriting the micromanagement of buffer characters
myself. But things like vi_go() don't work on their own without run_vi_cmd(), and reading through
both doesn't give me much insight to me on why. I'll dive into it more with debug printf-ing eventually.

I'll take your advice on how to make backspace-ing jump over lines. And will probably
replace the existing run_vi_cmd logic with the direct logic in a future patch to vi.c
(I still don't know the "proper" way to submit fixes for pending patches, which has
existed since my first patches for ts.c in September. Submitting a patch to do
another commit on top of the old patch to fix whatever is bad seems reasonable? But
then again it doesn't seem more "correct" than making another, better version of the
old patch that can be applied to a unmodified codebase and just re-submitting that)

> > > https://www.cs.unm.edu/~crowley/papers/sds.pdf

Thank you for this by the way.

> If someone needs them, I think
> first thing to do is implement better ex command parsing and
> dispatching, original version was intended only to parse write and
> quit commands.

Right now it's a large if/else staircase with loop (2addr) processing at the end.
It doesn't have the infrastructure for the whole [2addr]cmd[buffer][count][flags]
(Which has so many exceptions and special cases that just processing them individually
when they do show up individually is often more simple)

Advanced ex command magic stopped being used as often when people got used
to vi and it's improvements, 99% of the time I see/run a ex command that isn't
writing or quitting, it's ":%s/pattern/replacement/g", ":g/pattern/command", or
some close variant of that. Because they provide things that vi normal mode doesn't
and can't easily.

> (the 90% vi user case, rest of 9% not knowing how to
> quit and 1% needing something else)

I use vim for batch processing on files frequently, which involves a lot
of ":%s/pattern/replacement/g" and ":g/pattern/COMMAND". It may only be 1%
in your workflow, but replacing names/converting comments/processing large
blocks of similar statements is made a lot more convenient by things like
the s[ubsitute] command in my experience.

- Oliver Webb aquahobbyist at proton.me