Re: Pasting UTF-8 characters with bracketed-paste-magic seems broken in 5.1

[Bart Schaefer <schaefer@brasslantern.com>]

On Sep 11,  6:41pm, Peter Stephenson wrote:
}
} > Given this, if your patch from 36483 seems to work for you, go ahead and
} > commit it so you can do the 5.1.1 release.
} 
} I simply tried it with a few simple accented latin characters and it
} seemed to work.  It doesn't sound like it's had much testing otherwise.
} I've committed it.

Now that it's out:

(1) someone who was experiencing the multibyte problem should try it again

(2) it should be tested for the case where a multibyte character is bound
to a widget that has been declared in active-widgets

I'm actually pretty sure this is still broken for obscure cases, but in
fact the whole scheme in which multi-byte recognition is buried inside
the self-insert widget is probaby also broken for those same cases even
when simply typing.  E.g., if I override the self-insert widget with my
own, my widget is only going to get passed in $KEYS the first byte of
any multibyte character.  (Just verified this with 4.3.17.)

Compare:

  shove-in-LBUFFER() { LBUFFER+=$KEYS }
  zle -N self-insert shove-in-LBUFFER

Against:

  call-self-insert() { zle .self-insert }
  zle -N self-insert call-self-insert

With shove-in-LBUFFER, pasting a three-byte multibyte character results
in interpretation as three separate characters.  With call-self-insert,
the trailing bytes are picked up by getrestchar() and the insert works.

So we're no worse off than before, but this needs re-thinking.