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

["Bart Schaefer" <schaefer@brasslantern.com>]

On Jun 9,  7:01pm, Zefram wrote:
} Subject: Re: User-defined zle widgets and built-in widget failure
}
} 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.

I think we should tie the most common cases to standard scripting concepts;
e.g., failure should be a nonzero $?, and the numeric value of $? should
indicate the reason for failure.  It shouldn't be necessary to invoke "zle"
multiple times to find out this kind of basic information; further, it
makes it obvious how a widget writer sets the value, i.e., with "return".

} Or a more general possibility would be thingy array variables
} accessible via thingy names

Just how many thingys are we talking about here?

I suggest defining one array variable $ZLE (or whatever name you want),
and define the meanings of the array positions.  E.g., ZLE could be
equivlent to ($BUFFER $CURSOR $LBUFFER $RBUFFER) in the current scheme;
instead of BUFFER="the text here" you'd say ZLE[1]="the text here".
(I don't think you should literally do that, because the buffer chunks
are best accessed directly as scalars, but for purposes of example ...)

} (though I'd want to do a proper namespace separation, e.g., ${zle.feep}).

You're creeping dangerously close to Perl associative arrays, there.
Unless we're talking about a huge amount of data, just use numbered
positions in an array with a "sufficiently unique" name.

} 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?

I think I'd rather not have to rewrite my .z* scripts again.  How much
"moving" are we talking about?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com