[Toybox] [PATCH] vi: fix segfault

[Jacob Wahlgren]

> On March 15, 2019 at 6:10 PM Rob Landley <rob at landley.net> wrote:
> Linestack is also infrastructure that I was working on for vi, and I mentioned
> recently I'm thinking of removing it and starting over because nothing's using
> it and infrastructure in search of a user is bad.
> 
> There's a design tension between "I have consecutive block of ram I'd like to
> treat as discrete items" and "I want to insert/remove stuff". This not only
> shows up with vi (mmap a file but treat it as lines) but also with command
> shells (mmap a script). Having to make individual line copies is wasteful (copy
> to/from disk cache to process heap, plus memory fragmentation on nommu systems),
> but _not_ doing it is a nightmare to track object lifetimes. I keep meaning to
> sit down and design a structure that handles both cases cleanly.

Yeah this is definitely tricky. Intuitively, you'd want the file contents to start
off mmap'ed, and then swap out lines as they are being modified. This should minimize
memory usage and copying, at least when we have virtual memory. I have no experience
with nommu system, how much should they be considered in a design?

> Another problem with vi is I never worked out how much scalability I want. I
> have gigabyte-sized mbox files which I occasionally like to open with vi because
> I find it easier to navigate than less, and I was worried that the array of
> pointers to start of line at 8 bytes per line might scale badly with my standard
> "remalloc every 64 entries added" approach, but power of two growth could also
> get unfortunate there...

It might be better to start off with the simplest possible design to get something
working, and see where it leads.

> I could instead do a linked list, which means jumping to line ":1234567" becomes
> the expensive part

The most important part for me is fast startup and low latency for local operations.
I would not think less of a tool for taking a second to scroll through a million
line file. I'd think the main (initial) use case for toybox vi would be smaller
config and source files.

> Ahem. Easy for me to go down ratholes in some of these areas.

Definitely. I'll probably go look at how editors usually structure these things.
I've never written one myself, but it seems like a fun project.

/Jacob