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

[Peter Stephenson <p.stephenson@samsung.com>]

On Thu, 10 Sep 2015 08:45:16 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Sep 10,  4:57pm, Axel Beckert wrote:
> }
> } > (1) There is a problem handling multibyte characters in the built-in
> } > read-commmand widget; or
> } > 
> } > (2) There is a problem with using ${PASTED#$KEYS} to remove multi-byte
> } > characters from the beginning of the pasted text.
> } 
> } (2) looks fine on a first glance:
> } 
> } PASTED=äoö
> } KEYS=äo
> } echo ${PASTED#$KEYS}
> } ö
> 
> Yes, but KEYS is a ZLE local so its content may be escaped or something.

read-command doesn't explicitly handle multibyte characters in the way
self-insert does.  self-insert gets the remainder of the character.
That doesn't work for you because you want KEYS to be correct before the
self-insert.  KEYS refers to the level where you originally read the
keys, in getkeybuf() / getkeymapcmd(), and at this point you've only got
the initial byte.

So I'm not sure what the fix is.  I think it might be (despite what the
comment in getkeymapcmd() currently says) to move the special stuff down
to the end of getkeymapcmd() and posprocess it into keybuf, which isn't
very nice but, well.  I'll look later on.

Can't really see a good reason for not producing a bug fix version anyway,
though, since there's plenty of stuff needs fixing.

pws