zsh-workers
 help / color / mirror / code / Atom feed
From: Peter Stephenson <pws@ifh.de>
To: zsh-workers@math.gatech.edu (Z Shell workers mailing list)
Subject: Re: a plan for ZLE extendability
Date: Thu, 05 Dec 1996 15:21:30 +0100	[thread overview]
Message-ID: <199612051421.PAA27640@hydra.ifh.de> (raw)
In-Reply-To: "Zefram"'s message of "Mon, 02 Dec 1996 12:58:29 MET." <17029.199612021258@bookbind.dcs.warwick.ac.uk>

Zefram wrote:
> There is a need for ZLE to be extendable without having to write a
> binary module.
> 
> To this end, I have devised the following system.

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

> The third requirement (modification of buffers) can be met most generally
> by adding a special parameter -- perhaps $ZLE_BUFFER -- that can be
> assigned to.  $ZLE_MINIBUFFER would also be required.  To control
> the cursor position, $ZLE_BUFFER could be split into two parameters,
> representing the parts of the buffer before and after the cursor.

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.

> There is a need to be able to perform actual input even
> when the stack is non-empty.  Probably the neatest way to do this is to
> have a special thingy that (when at the top of the stack) will cause
> the input functions to perform input anyway.

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 "send string" functionality can be handled in one of two ways.
> The first possibility is to treat it as it is now, as a special case
> in getkeycmd().  The second possibility, that I generally prefer, is to
> make it into a normal ZLE function, taking an argument, and allow keys
> to be mapped to any sequence of thingies.

One thing that's missing at the moment is being able to bind to
sequences of functions, instead of just a rather opaque string of
characters which may or may not be bound to the desired functions, so
the second alternative is definitely desirable.  I think in any case
bindkey -s can easily be rescued to store an appropriate sequence.

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.

-- 
Peter Stephenson <pws@ifh.de>       Tel: +49 33762 77366
WWW:  http://www.ifh.de/~pws/       Fax: +49 33762 77413
Deutches Electronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen
DESY-IfH, 15735 Zeuthen, Germany.


  reply	other threads:[~1996-12-05 16:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1996-12-02 12:58 Zefram
1996-12-05 14:21 ` Peter Stephenson [this message]
1996-12-05 16:04   ` Zefram
1996-12-06  8:46     ` Peter Stephenson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199612051421.PAA27640@hydra.ifh.de \
    --to=pws@ifh.de \
    --cc=zsh-workers@math.gatech.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).