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