From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17909 invoked from network); 13 Jul 1999 13:24:18 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 13 Jul 1999 13:24:18 -0000 Received: (qmail 27280 invoked by alias); 13 Jul 1999 13:24:04 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 7113 Received: (qmail 27273 invoked from network); 13 Jul 1999 13:24:03 -0000 Date: Tue, 13 Jul 1999 15:24:01 +0200 (MET DST) Message-Id: <199907131324.PAA10284@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Peter Stephenson's message of Tue, 13 Jul 1999 14:40:16 +0200 Subject: Re: PATCH: Enhancing math expressions a bit 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@informatik.hu-berlin.de