Re: PATCH: more fun with `zle'

Re: PATCH: more fun with `zle'

[Sven Wischnowsky]

I forgot to say: this also adds`zle -U string' which puts the
characters from `string' back into the input-loop.

And: all of this is only a suggestion for things that may be
interesting to have. I'm not really happy with the argument-parsing
and -naming of `zle' (and I never really understood why we have to
have the concept of a widget -- maybe a special builtin/shell
function-type would be more appropriate nowadays; but that's a
different story).

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

RE: PATCH: more fun with `zle'

[Andrej Borsenkow]

>
> And: all of this is only a suggestion for things that may be
> interesting to have. I'm not really happy with the argument-parsing
> and -naming of `zle' (and I never really understood why we have to
> have the concept of a widget -- maybe a special builtin/shell
> function-type would be more appropriate nowadays; but that's a
> different story).
>

As I understand it, it gives you additional flexibility. You can have a single
function that is linked to more than one widget. Widget name is available so
function can behave differently. Currently I have e.g. function

((${+NUMERIC})) || zle .set-local-history
if [[ $WIDGET == .* ]]
then
    zle $WIDGET
else
    zle .$WIDGET
fi
((${+NUMERIC})) || zle .set-local-history

and redefine all *history* widgets to use this function. Implementing the same
directly as function would depend on FUNCTIONARGZERO setting.

/andrej

Chain widgets call (was: RE: PATCH: more fun with `zle')

[Andrej Borsenkow]

>
> ((${+NUMERIC})) || zle .set-local-history
> if [[ $WIDGET == .* ]]
> then
>     zle $WIDGET
> else
>     zle .$WIDGET
> fi
> ((${+NUMERIC})) || zle .set-local-history
>

And looking at this I realised, that it has some basic problem. Every other
*history* widget could already be redefined to whatever you like. What I want to
do is ismply to set special environment and call _original_ widget ... that is
not quite the same as calling .immortal version. But there is no way to "chain"
definitions ... Doing it would probably mean

 - special syntax to "push" instead of "replace" definition
 - special syntax with meaning "call previous definition for current widget"

And the question is, how generally useful is it at all?

/andrej