Re: User-defined zle widgets and built-in widget failure

[Zefram <zefram@tao.co.uk>]

Bart Schaefer wrote:
>I'd like to write a widget that modifies BUFFER, calls a built-in widget,
>and then if that built-in widget fails, restores the previous BUFFER and
>CURSOR.
>
>Unfortunately, failure of "zle whatever" isn't detectable; "zle" always
>sets $? to zero.

Failure internally is recorded by the feep flag.  If that is set at
the end of the main loop, a beep is emitted and the flag reset.  All we
need to do is make that flag visible to widgets.  Like a lot of other
ZLE things, this is one of the things I had a fairly concrete plan for
when my spare time suddenly disappeared last year.

The mechanism I planned is that each thingy will include a single-bit
flag, which can be tested and modified using the zle builtin.  Then all
you do to test for error is "if zle -F feep; ...", where the value of
"F" has yet to be determined.  Other thingies would have flags attached
similarly.  Or a more general possibility would be thingy array variables
accessible via thingy names, or possibly by more magic parameter names
(though I'd want to do a proper namespace separation, e.g., ${zle.feep}).

That reminds me, more generally I'd like to move the zsh-specific
parameter names to completely separate names that can't conflict
with POSIX parameter names.  If we have ${zsh.module_path} instead of
$module_path, then this can be available regardless of the name used to
invoke zsh.  What do people think?

-zefram