Re: Non-patch: zle argument handling

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Peter Stephenson wrote:

> I haven't bothered sending a patch for the merged changes, which will
> appear in pws-23, if I haven't lost count, but below are the documentation
> changes only (Sven, please look and see if I've missed any of your changes
> which I claim to have included) --- don't apply this, except to read, since
> there aren't any code changes to go with it.

As far as I can see now, it looks good.

> - Sven's read builtin changes

I was thinking about this some more. Maybe we should make this return
key in the same way as they are reported by the `keys' special
parameter? I.e. `C-a' instead of ASCII-1.
Maybe I'll produce a patch for this sometime this week so we can play
with it...

> - Sven's zle -R change

There are other things along this line we might want to think
of. E.g.: a way to put the cursor under the command line (a la
trashzle()). Probably even a way to redisplay the prompt after that
and saying that we have just printed n lines (I'm talking about
user-programmable alwayslastprompt-behavior).

> - My change to specify a numeric argument to zle with -N or -n <number>.
>   I didn't like "zle widget '' args" to call a widget with argument args
>   using the current numeric argument, since it's unclear and error-prone.
>   (This means the zle calls in Sven's example isearch function need
>   changing.)

I didn't like that either, I was just too lazy to implement more
sophisticated argument handling.

> I have not included:
> - Any way of aliasing widgets.  You need to defined a function to do
>   anything like this.  We can add something like this if and when we decide
>   it's necessary.

That's ok for me.

> Another possible suggestion: We could remove all the feep()'s from the code
> and feep() if and only if the widget returned 1.  For user-defined widgets,
> we could have a special function to allow them to feep and a special option
> to zle that will suppress the feep for any other widget, so that simple zle
> -N's work without extra error handling.  If there are times we need to
> return 1 internally but not feep, we could return 2 instead; that would
> also allow a widget to know if a function had failed but not feeped.
> (By the way, what does feep mean?)

No opinion here -- I always switch off all [bf]eeps.

Bart Schaefer wrote:

> Does this imply when called from that var(num) is ignored and exactly one
> key is read regardless?  That seems broken to me.  If that's not what it
> means, then what difference does it make that zle is involved?  Things
> should only get documented if they are visible behavior changes; and then
> what you need to document is the behavior, not the implementation.

Of course it reads multiple keys (and without `-[kq]' it reads anything
up to the next `\n').
Maybe we should just say that `read' also works inside zle widgets? Or 
would every user expect this? Does everyone know about `read'? We had
some questions about accessing the command line inside completion
functions after all. Maybe we should just say that keys can be read
inside zle widgets in the zle docs?

Btw.: do we want to have a way to read a key sequence (relative to a
keymap)? A way to look up a key (-sequence) in a keymap?

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx