Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: PATCH: Enhancing math expressions a bit
- X-seq: zsh-workers 7113
- From: Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxx
- Subject: Re: PATCH: Enhancing math expressions a bit
- Date: Tue, 13 Jul 1999 15:24:01 +0200 (MET DST)
- In-reply-to: Peter Stephenson's message of Tue, 13 Jul 1999 14:40:16 +0200
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
Peter Stephenson wrote:
> Sven Wischnowsky wrote:
> > This does that: it replaces `keys' with `KEYS' and that contains the
> > literal character codes.
>
> Well, here's some documentation.
Ouch, sorry.
> But I'm worried about what happens with
> control-space. Might it not be better to use an array with the literal
> codes in (so a null-string means ^@), or alternatively provide a length
> parameter, or use some form of metafication?
(Now I finally understood why you mentioned that lately...)
Urgh, yes, this is ugly (at least $(( #keys )) correctly returns zero
in this case). I wouldn't be against going back to some kind of readable
form, but I would really like to have it report keys in the same way
as `read'. Maybe it would be better to leave `keys' alone and add an
option to `read' that says that keys are to be reported as arrays of
bindkey-like strings? (Hm, -K is unused.)
The solution with a separate number-of-keys parameter looks a bit odd,
doesn't it?
> > Now, should we add a way to turn such codes into a readable form?
>
> Can probably be done quite simply with a shell function, which could be
> marked #autoload if needed.
Yes.
Bye
Sven
--
Sven Wischnowsky wischnow@xxxxxxxxxxxxxxxxxxxxxxx
Messages sorted by:
Reverse Date,
Date,
Thread,
Author