Re: bracket-paste-magic adds backslashes inside a quoted string if URL is pasted ("regression" compared to pre-5.1 url-quote-magic)

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxx> 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)