From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21253 invoked by alias); 11 Sep 2015 08:10:47 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 36486 Received: (qmail 4203 invoked from network); 11 Sep 2015 08:10:46 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 X-AuditID: cbfec7f5-f794b6d000001495-e9-55f28c80d070 Date: Fri, 11 Sep 2015 09:10:31 +0100 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: Pasting UTF-8 characters with bracketed-paste-magic seems broken in 5.1 Message-id: <20150911091031.0a227ebd@pwslap01u.europe.root.pri> In-reply-to: <150910162415.ZM3990@torch.brasslantern.com> References: <20150906155751.GD3721@sym.noone.org> <150910073920.ZM21998@torch.brasslantern.com> <20150910145714.GO3721@sym.noone.org> <150910084516.ZM22892@torch.brasslantern.com> <20150910170705.0fbeb302@pwslap01u.europe.root.pri> <150910091649.ZM3715@torch.brasslantern.com> <20150910172840.0a1899f4@pwslap01u.europe.root.pri> <20150910195713.340861cb@ntlworld.com> <20150910203527.260abe86@ntlworld.com> <150910162415.ZM3990@torch.brasslantern.com> Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsVy+t/xK7qNPZ9CDY6UWhxsfsjkwOix6uAH pgDGKC6blNSczLLUIn27BK6MZRtXsxfM5a64M2kJcwPjN44uRg4OCQETicb9Fl2MnECmmMSF e+vZQGwhgaWMEj9uOXcxcgHZM5gkLk29wQKR2MYoMeNjHYjNIqAqcebobmYQm03AUGLqptmM ILaIgLjE2bXnweqFBcIkLrZPBIvzCthL7JmxBmwBp4ClxLFbBxkhFlxmlvj04iPYIH4BfYmr fz8xQVxkLzHzyhmoZkGJH5PvgQ1lFtCS2LytiRXClpfYvOYtM8Rx6hI37u5mn8AoNAtJyywk LbOQtCxgZF7FKJpamlxQnJSea6RXnJhbXJqXrpecn7uJERKwX3cwLj1mdYhRgINRiYfXQvVT qBBrYllxZe4hRgkOZiURXtsOoBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHembvehwgJpCeWpGan phakFsFkmTg4pRoYF54LSv51luGu3skZx64bLtr3NF19+2av9qk3z3y8fnF6reSx5ucF9p/n nowRPZbxYpnGzFmhE9SCDnrc5Z5yI3H1Xz1Tt26bx8xyq6dXvY5nnh+R8efMcva9e/1Efm8y 2GjslMl/gW9vYWVpzu/fsaVHO6stGJISvohOWSly3nfiuvfrgy3OqimxFGckGmoxFxUnAgBo pW7lVAIAAA== On Thu, 10 Sep 2015 16:24:15 -0700 Bart Schaefer wrote: > On Sep 10, 8:35pm, Peter Stephenson wrote: > } > } This seems to be getting somewhere, but possibly needs more expert > } examination... > > This diff looks OK, though I'm not sure why you need $ismb ? Is it just > a shortcut? (i.e., because if the multibyte character had been bound to > something, then .read-command would have consumed it as one $KEYS, so > we know it can't match $bpm_inactive) It didn't work otherwise. I don't know what the pattern match was doing that would cause it to go down the wrong way. > Thinking harder, though ... isn't the only reason that this gets "stuck" > because "zle .self-insert-unmeta" blocks waiting for more bytes? Do we > really need the loop-within-a-loop given LBUFFER+= instead? Perhaps > because the trailing part of the multibyte character might be bound to > an active widget? That's correct about self-insert, but if we don't have the loop, I'm not sure we've done enough analysis to decide between executing a command and putting stuff in the buffer. But feel free to experiment as you know the sort of things that should work. I should say I don't really have any interest in this beyond getting it basically working as a proof of concept --- if you want to tweak it further, go ahead. An elegant fix to the internals of the line editor can wait. pws