[Bug-zile] Zile in Lua just in

[Reuben Thomas]

Well, not quite, there are some bits of C left which bind signals and
various other features, and then call Lua, rather than the other way
around, but it's only a few hundred lines, which will mostly be farmed
out to libraries, and all the actual editor is in Lua and the C-to-Lua
bridge (clue) has been burned.

There remains a lot to do. 6 tests in the test suite currently fail,
but they've been failing for a while now; I just didn't bother fixing
them until I'd finished translating the code into Lua. The Lua itself
is fairly nasty in places, in proportion as it's a direct translation
from C.

But before fixing all that, I need to fix the build system, which
itself needs to vanish, or rather, be outsourced. First will be a new
release of lrexlib, with GNU regex support (that is in fact ready to
go, and should happen later this evening). Secondly, lcurses and
lposix both need updating, and in the former case, I will probably
adopt the project, as it seems to have been abandoned. lposix will
need to be autoconfiscated to take advantage of gnulib, without which
it will seriously hamper the portability of Zile, and with which it
will greatly increase its own portability. I also have to add in the
missing bits which I've bound by hand, not least getopt_long.

After that, I'll make a first alpha release of Zile 2.4.

At some point, I will also make another Zile 2.3 release, as I have
accumulated some fixes and improvements; and I'd also like to return
its code to the less verbose and more efficient structure member
syntax rather than the accessor method syntax I adopted for the
translation process (ironically, the Lua code I wrote with structure
member syntax, so it now looks more like the C used to look). I think
I owe it to the immense amount of work I've done on the C over the
years to leave it in good shape syntactically, at least, even if it
could do with a lot more structural TLC. Essentially, it's amazing
quite how horrible a really rather small amount of code, written by
just a few people over a few years, can end up. And I must already
have spent the equivalent of several months' full-time work just
improving the C.

(Should anyone ever be interested, what remains to be done is:

1. Express the data structures better. I am going essentially to go
back to a public interface, because the pure method-based interface I
now have just looks horrible in C. I don't know whether something
based on Chris Fraser's "Interfaces in C" might be better, or just
allowing that public structure members are OK, and separating out the
public from the private. Maybe in fact it's time to rewrite in C++ or
Objective C, but after seeing how much better things have been able to
get, I'm far from convinced that I've remotely reached the limits of
how nicely one can do things in C.

2. A better dynamic string library (based on Lua's?) would make most
of the memory allocation headaches go away (it's usually only strings
that have an indeterminate scope).

3. Still, garbage collection would be nice.

The rest applies to Lua Zile too:

4. The buffers should be implemented as ropes, or as two strings (as
in Emacs). Either simplifies things; ropes scale better.

5. The minibuffer needs to be implemented as just another buffer, not
a special-purpose event loop, which reimplements a mini-Zile (MILZ?)
inside itself.

6. A proper buffer object with editing primitives is needed, so that
we have a proper demarcation between core editing and derived editing
functions. In Lua Zile this is particularly important so that we can
re-start Zee, and have the current (intended) Zee interface and Zile's
sitting on top of the same core. (This also implies separating the
multi-buffer and windowing interfaces out, as Zee does not use them.)
Some derived operations are used by both Zee and Zile; that's fine, as
it's like the current derived methods in astr.c in C Zile: they're
primitives from the point of view of Zile, but derived in astr.c.

-- 
http://rrt.sc3d.org