Re: zle_line_init_functions (Re: accept-line-and-down-history and push-input)

[Peter Stephenson <p.w.stephenson@ntlworld.com>]

On Wed, 27 Oct 2010 08:40:31 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> Also either way I think zle_line_init_whatever should preserve the
> behavior of abandoning the remaining hooks if any one of them fails.

That's easy and sensible --- I interpret "fails" as errflag != 0.

> } If you have the behaviour buried in the widget itself it looks
> } different from the other hooks which are independent of the definition
> } of the base function.
> 
> That's a different issue, and one where now that you point it out, I
> agree with you.  Rather than have zle-line-init itself walk through
> the array, I'd amend to suggest a second nameless widget that can't
> be replaced by "zle -N" whose purpose is to walk the array, following
> the structure of your patch in user/15493 more closely.

This isn't so different from what I proposed, and has the attractive
feature that you only have the one namespace --- there's no point in
having functions named differently from widgets if you're explicitly
saying which to call, so that makes sense.

An unnamed widget doesn't fit in well with the scheme of defining
widgets, so I called it hook-runner.

Alas, it still doesn't work.  Because the widget is built-in, there's no
point at which the zle parameters get added --- the hierarchy is
builtin widget -> ordinary shell function --- so you can't see (e.g.)
$KEYMAP, which is crucial to being able to handle zle-keymap-select
neatly.

So we need a function widget at the top level, as in my original
proposal, or rewrite the internals, a route I'm not going to take ---
that doesn't mean it's not workable, it just means I've decided I've
tried hard enough at this point.

> } Also, if you do it the other way, within zle you have to do something
> } more complicated than I've just written that performs an extra level
> } of indirection to call a whole heap of other widgets.
> 
> I'm not following the origin of this whole heap of other widgets.
> 
> } Then all the widgets have to be predefined in the appropriate
> } configuration file.
> 
> We must have disconnected somewhere because this is (a previously
> unstated) part of my objection to a zle_line_init_widgets array.

The point was that in your original suggestion you'd need *always* to
have widgets called zle-line-init etc., even if they didn't do anything,
just to run the hooks, even if you hadn't defined any.  In my scheme
you'd only have widgets defined when they'd be run in a hook.

> } It doesn't make sense to me to have a whole new set of callable zle
> } functions that aren't widgets, it creates a new category that blurs
> } the boundaries.
> 
> I think that's a barn from which the horse has already escaped; we
> already special tests used in traps when called from zle, various
> "Utility Functions" like modify-current-argument, and of course the
> entire collection of completers and their helpers.

In these cases the functions aren't called from zle directly.  There's
at least one case where a function is, however, which is a zle -F
handler; but that doesn't do editing, it just handles input, and is
deliberately written so the function doesn't interact with the editor.
I agree the distinctions are a bit blurry for your average user, though.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/