Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
RE: PATCH: Enhancing math expressions a bit
- X-seq: zsh-workers 7006
- From: "Andrej Borsenkow" <Andrej.Borsenkow@xxxxxxxxxxxxxx>
- To: "Sven Wischnowsky" <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>, <zsh-workers@xxxxxxxxxxxxxx>
- Subject: RE: PATCH: Enhancing math expressions a bit
- Date: Wed, 7 Jul 1999 15:40:25 +0400
- Importance: Normal
- In-reply-to: <199907070815.KAA08971@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
>
> I was finally tired of using tests like [[ '#key' -eq 8 ]], so this
> changes getkeystring() so that it can also parse only one character
> (btw, maybe we should turn the `fromwhere' argument into a flags
> argument and add some constants some day). The it makes math mode use
> this function to get the ASCII-value of a character. I.e. you can now
> say [[ '#key' -eq '#\\C-h' ]] and things like that.
>
> I'm not sure if this is the way to go
It surely is useful, but I'd still like to have widgets instead of (even
symbolical) raw bytes ...
Looking at how e.g. incremental search is implemented - it looks, like it simply
calls the same getkeycmd() as main zleread() and some friends. How hard would it
be to provide a builtin, let's say zgetkeycmd (may be, flag to read would do)
with something like
zgetkeycmd widget keys
that simply sets parameter `widget'' to widget name and parameter ``keys'' to
input string? Looks like just a wrapper around getkeycmd() (or am I wrong?)
Combined with suggested keymap switching, this would provide almost unlimited
possibilities.
/andrej
Messages sorted by:
Reverse Date,
Date,
Thread,
Author