Re: a plan for ZLE extendability

[Zefram <zefram@dcs.warwick.ac.uk>]

>this sounds fine... someone ought to make a few comments...

That's what I thought.  I'm surprised no one has responded up to now.

>You can avoid $ZLE_BUFFER by doing like what completion does and
>passing the buffer as arguments $1 and $2 of the function.  I think
>the drawback is you need some kind of arrangement with the function
>call mechanism to get the returned values of $1 and $2; maybe nested
>functions are less intuitive and less efficient this way, too.

I considered using the positional parameters -- actually I would have
used them for the thingy stack -- but I decided that the hiding of
these parameters when another function is called would make it
inappropriate.  I don't like this aspect of completion functions,
partly for this reason.  It is also aesthetically displeasing, and
illogical, to make changes to the buffer by assigning to the function's
arguments.

>What's the objection to e.g. having a special option to zle that
>causes the arguments to be executed immediately?  Or one that causes
>just the top N thingies on the stack to be executed (or the possibility
>of both)?  That would avoid having special thingies.

The effect of such an option would be equivalent to pushing one of the
special thingies, and then the thingies specified.  There would in
practice still be a need for a special thingy.  (There's no overhead in
that; there are other things that require thingies to have flags too.)
The syntax I am currently leaning towards would have

zle -h

to push a special thingy, {h}iding the rest of the stack; normal
thingies could also be specified, so

zle -h get-key

would push a special thingy and then push and execute get-key.  The
result would be the key read as the only visible thingy on the stack;
after that had been popped, the special thingy could be popped.  Is
this close enough to what you had in mind?

>                                                 I think in any case
>bindkey -s can easily be rescued to store an appropriate sequence.

Of course, the existing semantics of bindkey -s would be emulated.

>I didn't quite get whether thingies are typed: are (1) thingies
>interpreted as functions when first popped and only as strings when
>required as an argument, or (2) either pushed on the stack as
>functions or as strings?  If (2) then a string encountered as a
>function can simply be sent without needing any specific send-string
>function.

(1).  Each thingy (apart from the special hiding thingy) is just a
string, as far as the user is concerned.  (Internally the thingy also
has a couple of flags.)  When a function execution is requested, the
top thingy on the stack is popped and looked up as a function name, and
that function is then executed.  In any case, automatically pushing
executed strings back onto the input would be inappropriate.  Tty input
is not fundamental to this model of ZLE; it's just something handled by
the get-key function (with which send-string collaborates).  A user
could even redefine get-key and send-string, to take input from
somewhere else.

-zefram