Re: A Couple of "Where Lua Is Used" Updates

["Gary V. Vaughan" <gary@...>]

Hi Steve,

Thanks for your interest!

On Sep 23, 2013, at 11:13 PM, steve donovan <steve.j.donovan@gmail.com> wrote:
> On Mon, Sep 23, 2013 at 3:28 PM, Gary V. Vaughan <gary@vaughan.pe> wrote:
>> Something else interesting that's falling out of the reorganisation is that I now
>> have 75% of a Lisp -> Lua translator (a la moonscript), which I think I'll work
>> on finishing sooner rather than later..
> 
> At this point, I feel I need some background on the Z* projects.

Zile used to be (and as far as the released versions from the C branch are
concerned, still is) a micro-emacs, complete with crippled micro-lisp also
implemented in C.

Reuben Thomas made an heroic line-by-line translation of that project into
(very un-Luaish) Lua relying heavily on (then lcurses, since rolled into…)
luaposix, lua-stdlib, lrexlib-gnu, and others which piqued my interest
enough to join the project.

At first, I just helped Reuben make the code more Luaish, ejecting many
lines of code along the way as C idioms gave way to more efficient Lua
idioms.  During that period I realised that what I really wanted was an
emacs-like editor programmed in Lua rather than Elisp, so I forked the
code and worked on that.  The tip of the zi branch in git got pretty far,
including a mostly TextMate compatible lrexlib-oniguruma syntax hiliting 
engine needing only a bit of hand-tweaking of TextMate hiliting modes to
make them Zi compatible (I ported the Lua and C modes since that's all I
was using at the time).

However by this point, editing a large file became annoyingly slow, even
with highlighting in a lazy coroutine that played catch-up when Zi was not
busy reading key presses and updating the display.  Time for a rethink and
to re-architect the whole thing, given lessons learned so far.  Reuben once
suggested that it would be really nice to have an editor building kit that
provided many of the algorithms (e.g. gap-buffer maintenance) and structures
(e.g. syntax highlighting) that are reimplemented over and over by editor
developers, and to build a micro-emacs over that as an example. That seems
like a fine idea to me - hence the change of tack with the Zile project that
I referred to in my last post.

With the simplification of the C-Zile Lisp implementation into Lua, it was
clear that it was little more than a glorified option setter incapable of
much of anything else, and I noticed that Lisp is so easy to parse that the
Lua-Zile re-implementation was only a few supporting functions away from
being a Lisp->Lua translator, and that taking some extra care with the
implementation left it configurable enough that it could easily be tweaked
to support a more scheme-like Lisp, or CL or whatever.  The 75% solution
I spoke of is in the lua branch of Zile's git repo.

And then Reuben said he wanted to spend less time programming and I fell
into the lua-stdlib rabbit-hole as I took over maintenance of Zile, then
lua-stdlib, then luaposix -- and haven't quite climbed back out yet to
get back to the Zile stuff I really want to work on.

>  Ever
> since I've used Emacs, I thought it was a fantastic thing, pity about
> the scripting language and its weirdly-borked implementation. (24-bit
> numbers, anyone?).

I used Emacs as my main editor from 18.59 through Emacs 22 or so (I think
some of my Elisp is now distributed in the core, though I wouldn't swear
to it) but as it became bigger and harder to get running on some of the
weird platforms I use regularly, I found myself using vi more often than
not (and being annoyed at it more often than not!), which is a shame
because I still like Emacs a lot.  It's just big and ugly by modern
standards, but still a marvel of engineering.

> That something with the Emacs philosophy (Small-ish
> C core, everything else done in Lua) would work very well (Mitchell's
> Textadept is something very much in that direction. He is very proud
> of his 2000 lines of C that shall not be extended)

For some reason I haven't been able to find a critical mass with TextAdept,
even though in principle I like everything it does philosophically speaking.
Perhaps because I am in the terminal most of the time, I prefer an editor
that runs there.

The curses front-end to Zile is theoretically abstracted away to the point
where swapping it out for, say, a Mac OS graphical front-end is just a 
simple matter of programming, for those of us that prefer a nice GUI to
curses in the terminal.  I say "theoretically" because with only the one
curses front-end actually implemented, there are surely some pain points not
yet encountered lurking in the existing code.

>> Unfortunately, I've been mostly distracted by supporting infrastructure (luaposix,
>> lua-stdlib, Specl, etc.) since I wrote that
> 
> Tell me about it! LDoc is now a bigger project than Penlight, and it
> was initially 'just' to support my documentation needs on that project
> ...

Then, I am in good company, at least :) One of the remaining TODO items
for luaposix is to move from LuaDoc to LDoc for consistency with stdlib
and full Lua 5.2 compatibility.

I hope that covers the background you needed, but feel free to ask if I
missed anything else you'd like to know.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail