[Edbrowse-dev] text line manager

[Karl Dahlke <eklhad@comcast.net>]

> but I'd rather get all the good things we're doing at the moment stable and
> ready for release

Oh definitely.
And to this end I have made my last substantial push,
hoping that all future changes are small bug fixes.
Then maybe in a month or two we call it a release.

This change removes any hard limit on the number of lines
in the ongoing edbrowse session, and has a new bookkeeping procedure thereof.
Garbage collection for strings / lines is described in buffers.c line 443.
The limit you will reach now is out of ram malloc failure,
which exits somewhat ungracefuly,
but is still better than a seg fault.
Actually in a large system, with large files, we could overflow the integer,
and not realize it until indexes are bad and trouble.
We need to globally use size_t instead of int when building our growing strings
and indexing arrays and so on.
Adam's right though, save that for the next version.
Nobody has overflowed an integer index yet.

Now for the warning.
I have the disclaimer in README about how I'm not responsible
if edbrowse trashes your files, and it never happened to me before,
but it did a couple of days ago.
It was my first rewrite of the text line manager,
and I edited a small file and it worked great, so being coky,
I made a small change in a large file, an important file,
without a recent backup, and saved, and the whole file was corrupted.
I was pissed!
I fixed that bug, and have been using edbrowse, and am still using it, even now,
but I would encourage you to run system backups,
and maybe even have a spare edbrowse executable around,
and then give it a whirl.
It is time for caution, but,
never up, never in.

Also a new debug level 8, that helps me debug the text line manager.
Shows each line of text that is freed.
Lots of output, so only use it on small files.
Remember, lines not in the buffer
may still have to stick around for the undo command,
then finally go away on the next undo command;
but sometimes an old line should be freed right away,
like in directory mode where there is no undo command,
or when browsing, wherein javascript side effects make undo impractical.
It's just more complicated that it first seems,
but I have db8 going now and it looks ok,
so give it a try if you dare.
My next brave moment is trying it on a database.
One thing to trash a file, another to trash an entire sql table.
Hopefully that won't happen.
And that's another venu without an undo command,
so I need to watch the text manager.

Karl Dahlke