[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: [ANN] rl-completer release 1
- From: Jay Carlson <nop@...>
- Date: Sat, 2 Apr 2011 13:35:32 -0400
On Wed, Mar 30, 2011 at 3:20 AM, steve donovan
<steve.j.donovan@gmail.com> wrote:
> On Wed, Mar 30, 2011 at 9:01 AM, Patrick Rapin <toupie300@gmail.com> wrote:
>> [1] http://lua-users.org/wiki/CompleteWithReadline
>
> Also note on that page that someone has packaged this as a plain C
> extension - definitely the way to go.
I find that statement ambiguous. Do you mean that it is preferable
that completions are deduced in C (Mike Pall did that, I didn't like
it) or that it is packaged as a DSO loadable by a vanilla interpreter
(with some...fun handled by a relatively modern dynamic linker)--as
opposed to a patch to lua.c, I would assume. Or maybe with the default
lua code const char*'d in so there's just a .so to keep track of, not
a .lua too.
Not that I see the alternative, but this what I've come to think of as
a typical Lua situation: when batteries are not included, nobody
remembers whether there are enough batteries at home, so extras are
bought. There are around three reasonable alternatives for what the
Lua->readline hook interface details are, and they aren't all that
interesting as long as all the portability angles are covered: don't
blow up in a non-readline interpreter, don't link a second copy of
libreadline in, don't let completers bring down the Lua runtime, don't
do worse at thread management than the repl, use the platform's
linking conventions, etc. Given sufficient time, they will all be
written....
For me, the interesting part of the whole problem is what user
interface improvements can be made in a completer (and more generally
in a readline-aware world) and completions on keywords are obviously
going to be part of that. Bringing in a partial code parser for
context could be useful too. The C layer is just overhead for those
projects.
As you might have noticed I wasn't particularly interested in
maintaining the C layer I wrote; it was part of a weekend of just
solving random frustrations while working on other things. I think I
did lua-lint somewhere around then and abandoned it too (although a
coworker mentioned he found it useful in 5.1; in some sense it wasn't
abandoned so much as finished). Anyway, I'd imagine getting a common C
layer together is doable because there are no particularly aesthetic
choices in how to do it (they're all drab.)
Dumping stuff on the wiki is fun and easy and lets you claim "did that
first" but it does sort of lead to wildly varying quality. Maybe
somebody (or some small group) with well-regarded taste could award
gold stars to pages or solutions that people should look at and add
keywords etc; become curators for not the hidden treasures but the
"everybody should know about this" parts normally fulfilled by
inclusion in lib/ or contrib/ in a batteries-included platform like
Python?
It's possible rocks are performing this function now; I haven't been
paying attention.
Jay