zsh-workers
 help / color / mirror / code / Atom feed
From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: bracket-paste-magic adds backslashes inside a quoted string if URL is pasted ("regression" compared to pre-5.1 url-quote-magic)
Date: Thu, 19 May 2016 21:14:58 +0000	[thread overview]
Message-ID: <20160519211458.GD8007@tarsus.local2> (raw)
In-Reply-To: <CAH+w=7aAtxrpcXg8nyGUE1mB1ifczMU1L13g7nqcoMp2f68LYg@mail.gmail.com>

Bart Schaefer wrote on Sun, May 15, 2016 at 04:59:27 -0700:
> On Fri, May 13, 2016 at 8:00 PM, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> >
> > Asking the user to explicitly invoke from pre-redraw all plugins that
> > need to be invoked from pre-redraw would be a compatibility / upgrades
> > nightmare: whenever a plugin that previously didn't use pre-redraw would
> > want to start using pre-redraw, all that plugin's end users would have
> > to edit the Single Master Pre-Redraw Function in their .zshrc's, in
> > lockstep with installing the updated plugin.  This would simply not
> > scale.
> >
> > What would scale is an interface similar to the one add-zsh-hook
> > provides for non-zle hooks: an interface that allows an arbitrary number
> > of registrations, where the various registrants — be they the user's
> > .zshrc or plugins — need not know or care whether there are other
> > registrants.
> 
> I was never very happy with the built-in variables for lists of hooks,
> particularly because they needed an externally-defined helper
> (add-zsh-hook) to make them practical.  I think add-zsh-hook could
> have been written entirely in terms of the original precmd et al.
> functions without the corresponding variables.
> 

Fair enough.

> Hence I also think that a plugin registry for the special zle hook
> widgets ought to be implemented externally, and the plugins agree to
> make use of it -- because if the plugins don't follow such a
> convention then the user has to update .zshrc in lockstep with the
> plugin installation anyway.

I don't follow your reasoning: whether .zshrc needs to be updated
manually is orthogonal to how the plugin hooks into zle.  It is about
the mechanism used by zsh to find and run the code that _installs_ the
zle hook, not about whether said installation is done by directly
calling builtins and defining specially-named shell functions or by
calling some registrar function.

(That is: even if a plugin foo uses a "plugin registry", the user would
still need to run «echo 'autoload foo && foo' >> .zshrc».)

I'm happy to keep this external, although if widgets shipped with zsh
used this "external" plugin, it'd probably become de facto official.

Cheers,

Daniel

> This convention could include allowing plugins to describe (or at
> least suggest) the order in which their hook should be called.


  reply	other threads:[~2016-05-19 21:21 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-06 20:53 Axel Beckert
2016-05-08 18:50 ` Bart Schaefer
2016-05-09 14:13   ` Vincent Lefevre
2016-05-09 15:41     ` Bart Schaefer
2016-05-10  8:58       ` Vincent Lefevre
2016-05-10 19:58         ` Bart Schaefer
2016-05-13  9:23           ` Vincent Lefevre
2016-05-13 11:06             ` Bart Schaefer
2016-05-13 12:19               ` Vincent Lefevre
2016-06-02  7:20                 ` undo problems/crashes (was Re: bracket-paste-magic ...) Bart Schaefer
2016-05-13 22:20               ` bracket-paste-magic adds backslashes inside a quoted string if URL is pasted ("regression" compared to pre-5.1 url-quote-magic) Daniel Shahaf
2016-05-14  1:33                 ` Mikael Magnusson
2016-05-14  3:00                   ` Daniel Shahaf
2016-05-15 11:59                     ` Bart Schaefer
2016-05-19 21:14                       ` Daniel Shahaf [this message]
2016-06-02  7:06                         ` zle hook conventions (was Re: bracket-paste-magic ...) Bart Schaefer
2016-06-03 20:40                           ` Daniel Shahaf
2016-06-03 22:51                             ` Bart Schaefer
2016-06-04 16:57                               ` Daniel Shahaf
2016-06-10 17:36                           ` Daniel Shahaf
2016-06-10 19:51                             ` 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=20160519211458.GD8007@tarsus.local2 \
    --to=d.s@daniel.shahaf.name \
    --cc=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).