bug-zile
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-zile] New branch `zi': Lua Zile without the Lisp Interpreter


From: Gary V. Vaughan
Subject: [Bug-zile] New branch `zi': Lua Zile without the Lisp Interpreter
Date: Wed, 10 Aug 2011 05:15:20 +0700

I've just checkpointed the last few days of patchsets by pushing them back to 
origin since I probably won't have much time to work on it for another week or 
three.

The main difference to the 'lua' branch is that instead of toting a lisp 
interpreter and writing all the configuration in lispy syntax, everything is 
now written in lua and evaluated in a sandbox environment.  I've updated all 
the existing test cases, and made sure that the entire test suite passes before 
each commit, so feel free to explore.

Zi allows nice things like a ~/.zi file that says:

  function nuke ()
    save_buffer ()
    save_buffers_kill_zi ()
  end
  global_set_key ("\\C-x\\C-y", "nuke")

  inhibit_startup_file = true
  fill_column = 72

I've used a nice decorator syntax for keeping the docstrings and other metadata 
declarations next to the functions exported into the sandbox:

  zi.random =
    docstring [[
  print a number between 1 and N.
  ]] ..
    interactive () ..
    argcheck ("number") ..
    function (n)
      print (math.random (n))
    end

There are still some warts:

  1. test coverage is not very good (on any branch!);

  2. it's inherited Lua Zile's sluggish performance;

  3. the execution sandbox is still pretty empty, so you can't do much apart 
from call the exported functions;

  2. the read syntax for keystrings is horrid because lua unrolls one level of 
\ escaping, Suggestions?;

  3. global_set_key should really take an actual function rather than a 
function name as it's second argument, then we could write:

      global_set_key ("\\C-x\\C-y", function () save_buffer () 
save_buffers_kill_zi () end)

I'll also trawl the sourceforge Zee mailing list archive at some point and port 
all the good ideas from there.

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]