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

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

[Bart Schaefer]

[>workers]

On Oct 26,  4:19pm, Peter Stephenson wrote:
} Subject: Re: accept-line-and-down-history and push-input
}
} On Tue, 26 Oct 2010 07:55:44 -0700
} Bart Schaefer <schaefer@brasslantern.com> wrote:
} > (I'm beginning to think that zle-line-init should be a builtin widget
} > that calls an array of hook functions, ala precmd.)
} 
} I've been thinking along those lines, except that the array of hook
} functions would be the alternative to the widget, as with chpwd and
} friends

I don't much like the idea of having an array of *widget names*.
What's the benefit of invoking a series of widgets, rather than
having one widget that calls a series of functions?  The context is
the same either way (i.e., "zle" with no args returns zero status
and you can access all the line editor variables) and all the work
of creating and destroying thingys can be avoided.

} i.e. you could still define zle-line-init if you wanted a
} simple life but zle_line_init_functions could contain an additional set
} of widgets.

Wouldn't you still get that effect if zle-line-init was a builtin
widget that you could override with your own via zle -N ?

} Not sure how to keep the name of the array entirely within zle

I don't know what you're reaching for, there.  The array has to be
outside of zle at some point or you can't assign anything to it ...?

zle-line-init() {
  local f
  for f in $zle_line_init_functions
  do
    if [[ $PWS_users_15493 ]]
    then zle "$f"
    elif [[ $my_suggestion ]]
    then "$f" || break
    fi
  done
}

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

[Peter Stephenson]

On Tue, 26 Oct 2010 22:01:02 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> } I've been thinking along those lines, except that the array of hook
> } functions would be the alternative to the widget, as with chpwd and
> } friends
> 
> I don't much like the idea of having an array of *widget names*.
> What's the benefit of invoking a series of widgets, rather than
> having one widget that calls a series of functions?

It looks like the way other hooks work.  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.

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.  Then all the
widgets have to be predefined in the appropriate configuration file. (I
imagine there would be a template C function where the widget examined
its name.) Before, no widget needed to exist at all; the whole thing
just required a single universal function and a simple function call
for each hook and you only created widgets as needed.  That's the
system I want to extend.

> The context is
> the same either way (i.e., "zle" with no args returns zero status
> and you can access all the line editor variables) and all the work
> of creating and destroying thingys can be avoided.

There's no work of creating and destroying thingies.  Either the widget
exists, in which cases it's already referenced, or it doesn't, in which
case nothing is created and NULL returned.  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.e. you could still define zle-line-init if you wanted a
> } simple life but zle_line_init_functions could contain an additional
> set } of widgets.
> 
> Wouldn't you still get that effect if zle-line-init was a builtin
> widget that you could override with your own via zle -N ?

Depends if you want the current behaviour as well.  If someone submits a
suggestion that uses zle-line-init directly, which is how the shell
currently works, and someone else a suggestion that involves the hook
function, which would be neater, they can't both work without
modification.  Of course two suggestions using zle-line-init need work
combining anyway, but it's obvious in that case that the function/widget
can't do two different things.  It's less obvious --- particularly if
you've happily been using an earlier version of the shell and not
noticed the way the behaviour has changed --- that redefining
zle-line-init causes other facilities to disappear.  I don't want
to have to keep explaining this.

> } Not sure how to keep the name of the array entirely within zle
> 
> I don't know what you're reaching for, there.  The array has to be
> outside of zle at some point or you can't assign anything to it ...?

That depends on the interface, but I can't think of a better way
than an array.

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

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

[Bart Schaefer]

On Oct 27, 10:22am, Peter Stephenson wrote:
} Subject: Re: zle_line_init_functions (Re: accept-line-and-down-history and
}
} On Tue, 26 Oct 2010 22:01:02 -0700
} Bart Schaefer <schaefer@brasslantern.com> wrote:
} > What's the benefit of invoking a series of widgets, rather than
} > having one widget that calls a series of functions?
} 
} It looks like the way other hooks work.

My point being that it may *look* like it, but really it doesn't *act*
like it, because all the other hooks call shell functions but this one
calls zle widgets.

At the least the array name should be zle_line_init_widgets to make the
distinction obvious, and the doc for add-zsh-hook should be updated.
(Either way I suspect the internals of add-zsh-hook also need to be
updated, because the current set of hooks have simpler base names.)

Also either way I think zle_line_init_whatever should preserve the
behavior of abandoning the remaining hooks if any one of them fails.

} 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.
 
} 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.  If
it's an array of shell function names, you define the function and
put its name in the array like all other hooks.  If it's an array of
widget names, you must additionally remember to "zle -N ..." for
every function to make it a recognized widget, or it will silently
be skipped when the array is walked.

I'm also somewhat concerned about what happens if one of the widgets
in question has been installed with "zle -C" instead of "zle -N".  In
other contexts there are problems with normal widgets and completion
widgets calling one another.  Is completion context available at the
time of zle-line-init?

Incidentally, what happens on "zle send-break" in the 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.
 
} If someone submits a suggestion that uses zle-line-init directly,
} which is how the shell currently works, and someone else a suggestion
} that involves the hook function, which would be neater, they can't
} both work without modification.

Yep, with you on that one now.

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

[Peter Stephenson]

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/

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

[Bart Schaefer]

On Oct 31,  9:54pm, Peter Stephenson wrote:
}
} > 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.
} 
} 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

Ah, and hmm.  So there's no clever way to pull off the equivalent of
(pseudo-code):

    zle -N hook-runner (){ local f; for f in ... }

I.e., take an anonymous function that does what you want and make a
user-defined widget out of it?