zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-workers@zsh.org
Subject: Re: zle_line_init_functions (Re: accept-line-and-down-history and push-input)
Date: Wed, 27 Oct 2010 08:40:31 -0700	[thread overview]
Message-ID: <101027084031.ZM31108@torch.brasslantern.com> (raw)
In-Reply-To: <20101027102216.16719058@pwslap01u.europe.root.pri>

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.


  reply	other threads:[~2010-10-27 15:40 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <AANLkTin4qeNKcBt_TDzY2xt-XJ6aHVH257FOa6iriPSm@mail.gmail.com>
     [not found] ` <101026075546.ZM28500@torch.brasslantern.com>
     [not found]   ` <20101026161947.19279c58@pwslap01u.europe.root.pri>
2010-10-27  5:01     ` Bart Schaefer
2010-10-27  9:22       ` Peter Stephenson
2010-10-27 15:40         ` Bart Schaefer [this message]
2010-10-31 21:54           ` Peter Stephenson
2010-11-01  7:01             ` Bart Schaefer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=101027084031.ZM31108@torch.brasslantern.com \
    --to=schaefer@brasslantern.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).