From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3929 invoked by alias); 3 Nov 2016 09:46:21 -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: 39815 Received: (qmail 28382 invoked from network); 3 Nov 2016 09:46:21 -0000 X-Qmail-Scanner-Diagnostics: from mailout2.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.12):SA:0(-2.3/5.0):. Processed in 0.487199 secs); 03 Nov 2016 09:46:21 -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: cbfec7f5-f79ce6d000004c54-ba-581b0508a8be Date: Thu, 03 Nov 2016 09:36:05 +0000 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: Bug in ZSH's vi emulation Message-id: <20161103093605.06e92c45@pwslap01u.europe.root.pri> In-reply-to: <161102211243.ZM16026@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+NgFnrDIsWRmVeSWpSXmKPExsWy7djP87ocrNIRBod2iFocbH7I5MDoserg B6YAxigum5TUnMyy1CJ9uwSujDW3HjMXTOStuPb8ClMD4zKuLkZODgkBE4nXre1sELaYxIV7 64FsLg4hgaWMEiuWfmWBcHqZJA7cuMMO0zF9/S9WiMQyRokL+z9DOdOYJA7f2APVcppRYnrz CqjMGUaJpqUvGEH6WQRUJWbMug1mswkYSkzdNBvMFhEQlzi79jxQNweHsICaxPmGMpAwr4C9 xIp9rWAHcgpYSVyafwmsnF9AX+Lq309MECfZS8y8coYRol5Q4sfkeywgNrOAjsS2bY/ZIWx5 ic1r3jKD3CMh0MwuMeHdMzaQXRICshKbDjBDzHGRWDfjOyOELSzx6vgWqJdlJDo7DkLt6meU eNLtCzFnBqPE6TM7oKFnLdF3+yIjxDI+iUnbpjNDzOeV6GgTgijxkHh/s5sJIuwo8XeCzQRG xVlIrp6F5OpZSK5ewMi8ilEktbQ4Nz212FSvODG3uDQvXS85P3cTIzANnP53/OsOxqXHrA4x CnAwKvHwCnyTjBBiTSwrrsw9xCjBwawkwvufWTpCiDclsbIqtSg/vqg0J7X4EKM0B4uSOO+e BVfChQTSE0tSs1NTC1KLYLJMHJxSDYxbl30rUojl6hOxn7dk132HhS5pca8iVgTkz7T+Pq3G pN3iqKHvqT8ueue7lq3en5mqGWiSJKl6f2rIhqNbObXXdDstlfWcyBJkcWV32qnGPZPfC25d eKY3WI17v+DW1gMMwZ9ivj8wfqckXjaryaLr4QWm7+8+JlX/kuVsuPfm5fvHxT8nKPgpsRRn JBpqMRcVJwIA3+K3P/8CAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsVy+t/xa7pMrNIRBk3HrCwONj9kcmD0WHXw A1MAY5SbTUZqYkpqkUJqXnJ+SmZeuq1SaIibroWSQl5ibqqtUoSub0iQkkJZYk4pkGdkgAYc nAPcg5X07RLcMtbcesxcMJG34trzK0wNjMu4uhg5OSQETCSmr//FCmGLSVy4t56ti5GLQ0hg CaPE95lX2CGcGUwSPV0zmECqhAROM0rcaeaFSJxhlHh/fhFYgkVAVWLGrNuMIDabgKHE1E2z wWwRAXGJs2vPs3QxcnAIC6hJnG8oAwnzCthLrNjXygZicwpYSVyaf4kRYuZmJomP/duYQRL8 AvoSV/9+YoI4z15i5pUzjBDNghI/Jt9jAbGZBbQkNm9rYoWw5SU2r3nLDHGousSNu7vZJzAK z0LSMgtJyywkLQsYmVcxiqSWFuem5xYb6hUn5haX5qXrJefnbmIERtG2Yz8372C8tDH4EKMA B6MSD6/AN8kIIdbEsuLK3EOMEhzMSiK8/5mlI4R4UxIrq1KL8uOLSnNSiw8xmgIDZiKzlGhy PjDC80riDU0MzS0NjYwtLMyNjJTEeUs+XAkXEkhPLEnNTk0tSC2C6WPi4JRqYGRx4ZrNffVX kOXcmsnOcxYVP9y65pDt+bRYrYL+U7wZisdkj0fxWf2fFnclexanikZpsouFtl7JzpMs0oLi eyN+rjMouXjNUntpwHS1I6uW6fie+DCVW7xU+4rFzCm9FiLiLj/E5so2397YO/eZVKG3bvGh /tBNvHvWOvnMtJ5hPEHi5S85JiWW4oxEQy3mouJEAGPm2yK4AgAA X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20161103093607eucas1p1f60fcf987d71f9293505274948608c25 X-Msg-Generator: CA X-Sender-IP: 182.198.249.179 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: 20161103041250eucas1p159c0d7e2caf6a2303808cc630e2d2570 X-RootMTR: 20161103041250eucas1p159c0d7e2caf6a2303808cc630e2d2570 References: <20161005080921.GB26647@raspi> <161005101938.ZM12590@torch.brasslantern.com> <20161102045925.GA6763@fujitsu.shahaf.local2> <11719.1478105483@hydra.kiddle.eu> <161102211243.ZM16026@torch.brasslantern.com> On Wed, 02 Nov 2016 21:12:43 -0700 Bart Schaefer wrote: > On Nov 2, 5:51pm, 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. > > It's because of getkeymapcmd(): > > if(lastlen != keybuflen) { > unmetafy(keybuf + lastlen, &keybuflen); <-- here > ungetbytes(keybuf+lastlen, keybuflen); > if(vichgflag) > vichgbufptr -= keybuflen; > keybuf[lastlen] = 0; > } > > Seems like it ought to do the following? Or else use a temporary instead > of stomping on keybuflen. > > diff --git a/Src/Zle/zle_keymap.c b/Src/Zle/zle_keymap.c > index 3db4207..b5244b5 100644 > --- a/Src/Zle/zle_keymap.c > +++ b/Src/Zle/zle_keymap.c > @@ -1622,7 +1622,7 @@ getkeymapcmd(Keymap km, Thingy *funcp, char **strp) > ungetbytes(keybuf+lastlen, keybuflen); > if(vichgflag) > vichgbufptr -= keybuflen; > - keybuf[lastlen] = 0; > + keybuf[keybuflen = lastlen] = 0; > } > *funcp = func; > *strp = str; > Yes, I stared at this for a while but I think the intention is to take the (keybuflen-lastlen) null-terminated characters off the end and make them available for re-reading as input, leaving only the first lastlen in the key buffer. That means keybuflen needs updating at the end anyway, to get rid of those characters from the key buffer, so use of a temporary is immaterial. Comments when this was originally written probably wouldn't have hurt. pws