From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: Mikael Magnusson <mikachu@gmail.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: Sat, 14 May 2016 03:00:35 +0000 [thread overview]
Message-ID: <20160514030031.GA2530@tarsus.local2> (raw)
In-Reply-To: <CAHYJk3S9qPhCByg8T-mrRjgUNBs-ubFCGKDKT7qx9=yGepA8qg@mail.gmail.com>
Mikael Magnusson wrote on Sat, May 14, 2016 at 03:33:46 +0200:
> On Sat, May 14, 2016 at 12:20 AM, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > Bart Schaefer wrote on Fri, May 13, 2016 at 04:06:45 -0700:
> >> Stepping outside the box a little here -- when url-quote-magic was
> >> written there was no such thing as the zle-line-pre-redraw hook. It
> >> might be that a better approach would be to examine the entire buffer
> >> in that hook after the paste has finished and apply the quoting
> >> retroactively, rather than to do it character by character during the
> >> paste. (On the other hand zle-line-pre-redraw is thoroughly co-opted
> >> by popular plugins like zsh-syntax-highlighting.)
> >
> > So perhaps it's time to permit registering multiple functions to be
> > invoked at pre-redraw, as proposed in 37639? This way, z-sy-h and
> > url-quote-magic could each register a pre-redraw hook function.
> >
> > zle-line-pre-redraw has not yet been released: its interface can be
> > changed arbitrarily. z-sy-h will be updated to use whatever interface
> > zsh-5.3 will be released with.
>
> It's already possible to do
>
> zle-line-pre-redraw() {
> whatever code
> other code
> z-sy-h-hook
> yet more code
> }
>
> Surely there has to be some limit to how lazy a user can be?
>
You're assuming the user knows what is all the code that needs to be run
from pre-redraw. That need not be the case: the user may have N plugins
and not know which ones of them use pre-redraw, since the use of pre-redraw
by a given plugin might be an implementation detail of that plugin.
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.
z-sy-h uses add-zsh-hook, but I doubt many users of z-sy-h even know
that add-zsh-hook exists. I'd like the same to be true regarding
pre-redraw.
> Also, if multiple things register for this automatically, it feels
> pretty likely more than one of them will be trying to do highlighting
> and then things will be wonky. And if you modify the buffer in one of
> them like in the GP example, the order _definitely_ matters or you
> will have highlights in the wrong place, so the user will have to
> intervene in that case. If "plugins" are automatically registering
> your more generic hook interface, it is very difficult for the user to
> arrange for the order to be correct.
>
Yes, if one pre-redraw hook modifies the buffer and the other updates
$region_highlight, then they should run in this order. How do you
propose that this be achieved?
I think there are two ways: either (1) have plugins document their
ordering requirements, and leave it to the user to 'autoload X && X' the
plugins in a valid order; or (2) extend the widgets/hooks API so plugins
can tell zle what relative order to run them in.
Approach (1) is what z-sy-h uses today under zsh≤5.2 (which of course
lacks zle-line-pre-redraw, but still has a problem analogous to this
"inter-plugin hook ordering" problem).
> This has a weak NAK from me.
>
> --
> Mikael Magnusson
I respect your opinion, but I wish you would suggest an alternative. As
I said, asking the user to invoke all his plugins from pre-redraw
wouldn't scale.
Cheers,
Daniel
(offline for the next few days)
next prev parent reply other threads:[~2016-05-14 3:11 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 [this message]
2016-05-15 11:59 ` Bart Schaefer
2016-05-19 21:14 ` Daniel Shahaf
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=20160514030031.GA2530@tarsus.local2 \
--to=d.s@daniel.shahaf.name \
--cc=mikachu@gmail.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).