(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ää <jmaki...@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 aquahobby...@proton.me _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
