From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28822 invoked by alias); 2 Nov 2016 17:44:34 -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: 39808 Received: (qmail 19227 invoked from network); 2 Nov 2016 17:44:34 -0000 X-Qmail-Scanner-Diagnostics: from mailout3.w1.samsung.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(210.118.77.13):SA:0(-2.3/5.0):. Processed in 0.492682 secs); 02 Nov 2016 17:44:34 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: p.stephenson@samsung.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at samsung.com does not designate permitted sender hosts) X-AuditID: cbfec7f4-f791c6d000006eac-52-581a239ca5f2 Date: Wed, 02 Nov 2016 17:34:17 +0000 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: Bug in ZSH's vi emulation Message-id: <20161102173417.6b854c75@pwslap01u.europe.root.pri> In-reply-to: <11719.1478105483@hydra.kiddle.eu> 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=UTF-8 Content-transfer-encoding: quoted-printable X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFIsWRmVeSWpSXmKPExsWy7djPc7pzlKUiDOa9tLA42PyQyYHRY9XB D0wBjFFcNimpOZllqUX6dglcGX9aelkL9nNU/D98i6WB8QlbFyMnh4SAicSRlj0sELaYxIV7 68HiQgJLGSWWTpfsYuQCsnuZJC6vesEI0/Dv7w9GiKJljBK7m5whiqYxSXzsu8AK4ZxmlDjx YR4zhHOGUaJr83F2kBYWAVWJrtePmUBsNgFDiambZoONEhEQlzi79jzQHRwcwgJqEucbykDC vAL2EmuPn2AHCXMK6Evs/p0BEuYHMq/+/cQEcZC9xMwrZxghygUlfky+B/YNs4CmxNbd69kh bG2JJ+8gbpMQ+M8mcenHTWaQmRICshKbDjBDzHGRWPPqLSuELSzx6vgWdghbRuLy5G5oCPUz Sjzp9oWYM4NR4vSZHdBgtJbou32REWIZn8SkbdOh5vNKdLQJQZR4SOye8BHqZkeJ6Q3fGScw Ks5CcvYsJGfPQnL2AkbmVYwiqaXFuempxSZ6xYm5xaV56XrJ+bmbGIEp4PS/4192MC4+ZnWI UYCDUYmHd8dnyQgh1sSy4srcQ4wSHMxKIrwPFKUihHhTEiurUovy44tKc1KLDzFKc7AoifPu WXAlXEggPbEkNTs1tSC1CCbLxMEp1cAotmLN/mlZcenWfT/3i/17OEctSSTnaMiv5zy7owv+ xVSvuuUtLKBxt29Sd8XRszuLb23coNX1Kc/p4t6AQ2KTld78W/zFLzZ2iqjF9LY/nHN/F+pf Lmjem6TdvUr3+RZfRY0o65CAuZuPqVrMv126XiXeeqbIdf05H7ztjm4zbQysr9+20TtRiaU4 I9FQi7moOBEAIybvtf0CAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsVy+t/xy7q1ylIRBvtn8lkcbH7I5MDoserg B6YAxig3m4zUxJTUIoXUvOT8lMy8dFul0BA3XQslhbzE3FRbpQhd35AgJYWyxJxSIM/IAA04 OAe4Byvp2yW4Zfxp6WUt2M9R8f/wLZYGxidsXYycHBICJhL//v5ghLDFJC7cWw8U5+IQEljC KPH70QsoZwaTxNTnm1ghnNOMErtu7maEcM4wSnyYADGLRUBVouv1YyYQm03AUGLqptlgc0UE xCXOrj3P0sXIwSEsoCZxvqEMJMwrYC+x9vgJdpAwp4C+xO7fGRAjm5kk/rX9YQep4QeKX/37 iQniPHuJmVfOMEL0Ckr8mHyPBcRmFlCXmDRvETOErS3x5N0FVhBbCCh+4+5u9gmMwrOQtMxC 0jILScsCRuZVjCKppcW56bnFRnrFibnFpXnpesn5uZsYgVG07djPLTsYu94FH2IU4GBU4uHd 8VkyQog1say4MvcQowQHs5II7wNFqQgh3pTEyqrUovz4otKc1OJDjKbAcJnILCWanA+M8LyS eEMTQ3NLQyNjCwtzIyMlcd6pH66ECwmkJ5akZqemFqQWwfQxcXBKNTAmhb9vYtrnKMdwOPrO qg7+A1kVj954pk9apcTak6jeso/R401Y14XPhRZu+W9dtWZLuzR6n0oI5tgZtN8l6P5es/uz LRcI9YbE1jx/Oi3n0btJrsG9cqv0vlguLORqvbTy+OE6s0NLbqlaZLh+ndm65zHTzR15wYp2 lqcz/rRH/GEr0m9QWaLEUpyRaKjFXFScCABR6GesuAIAAA== X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20161102173420eucas1p16cce38de4958e8522118970ea0aefe7c X-Msg-Generator: CA X-Sender-IP: 182.198.249.180 X-Local-Sender: =?UTF-8?B?UGV0ZXIgU3RlcGhlbnNvbhtTQ1NDLURhdGEgUGxhbmUb?= =?UTF-8?B?7IK87ISx7KCE7J6QG1ByaW5jaXBhbCBFbmdpbmVlciwgU29mdHdhcmU=?= X-Global-Sender: =?UTF-8?B?UGV0ZXIgU3RlcGhlbnNvbhtTQ1NDLURhdGEgUGxhbmUbU2Ft?= =?UTF-8?B?c3VuZyBFbGVjdHJvbmljcxtQcmluY2lwYWwgRW5naW5lZXIsIFNvZnR3YXJl?= X-Sender-Code: =?UTF-8?B?QzEwG0VIURtDMTBDRDA1Q0QwNTAwNTg=?= CMS-TYPE: 201P X-HopCount: 7 X-CMS-RootMailID: 20161102165849epcas4p1d2a4453b73b7ff752824bd72aac19b27 X-RootMTR: 20161102165849epcas4p1d2a4453b73b7ff752824bd72aac19b27 References: <20161005080921.GB26647@raspi> <161005101938.ZM12590@torch.brasslantern.com> <20161102045925.GA6763@fujitsu.shahaf.local2> <11719.1478105483@hydra.kiddle.eu> On Wed, 02 Nov 2016 17:51:23 +0100 Oliver Kiddle wrote: > We've also got a separate issue of only lastchar being stuffed into > vichgbuf so repeating, e.g. gU doesn't work. Why is keybuflen only > 1 in startvichange? That, along with what the general point of lastchar > is, has me fairly puzzled. The thing that gets stuffed into vichgbuf[0] in startvichange() is the last byte of the binding that caused the change to start, not the range of the change. So if you issue "c" then the "c" goes into the buffer here and the target gets handled later. I haven't traced it further than that, but this would only screw up with atypical bindings for vi-change, vi-delete, etc. Presumably extracting the full set of bytes for the command would work. This wouldn't work with a multibyte binding, for example, e.g. if you had =C2=A2 on your keyboard and thought it would be a great alternative to c then only the last byte of the character would be stored. At some point I think it got fixed up so the keybuf is correct for cases like this. pws