From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15131 invoked by alias); 2 Nov 2016 16:58:20 -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: 39807 Received: (qmail 29002 invoked from network); 2 Nov 2016 16:58:20 -0000 X-Qmail-Scanner-Diagnostics: from nm33-vm7.bullet.mail.ir2.yahoo.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(212.82.97.112):SA:0(0.0/5.0):. Processed in 0.433377 secs); 02 Nov 2016 16:58:20 -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=0.0 required=5.0 tests=FREEMAIL_FROM,SPF_PASS, T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: okiddle@yahoo.co.uk X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _spf.mail.yahoo.com designates 212.82.97.112 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1478105484; bh=bo4N60qzYbsdZuDBZwiGIgmjS+FLaGCjdiBVv2g7IgI=; h=In-reply-to:From:References:To:Subject:Date:From:Subject; b=olGKRnrO+OuI9llNTU8DseulqdT36P3jkxmlSqfd8vkZ9B0FNSMlBOlZqhUKLEdLSJFSLmBduDpRb4JsuJKZYYGSWNK1dIz9zE2XHxqYXXn9ucXrza2f95GLh/bn3rfn+bf45mk+c4nETpBXudUL3oedV5G4lkK7GHMp2zSCG506dyJIzxlxdP5qxLVtoKl5Bp3lQl++H56uj+5j+teA9SwuoSu26SE2kjaTKT/eXdSlFMWSyO+Su+Y6HRZ826Ht1qjCx4UxmpX6DaF16Bzkx6cGJxkRQyEAZ61+MhFSEe1wA8288kXb5c8EfA9q5X/GgpnP+KZctK1CcHVJ+NVGOQ== X-Yahoo-Newman-Id: 797822.85472.bm@smtp135.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 0b1K6mQVM1l6VXnpHsOgfMh518Xg02FbZB1787HKBD1KYk. u5nJEp5__TnkgDgORA8xObQXCpxE6Jx4qw2Fo5XcH3FgNISr_zubXrmHrHp. a3BdDLPyFBzM9DMCc97tDDgIFd5IZtHuJuHrIKOTusucT2EdBu0AvM6v._1i iXOJ__0sX6pKN0bFU8dLsg.g_EjCme7kEx74ZP5kWvnSbqcp038.nfuAaeSR PFJYIFqVXsgyK5.9YRwcMmFF3m2G2_zcYKa8bWlik_R3I3Aar4AddV1AGCQH 17MivdV0zZQSOoE9yXIWUopXh6.hDm9I7YZv0PB.VG8qyGGRev7mV8eU3bJ1 Un33s3OFuTbpD2VoXQN57J1VKEbzCMSrFPexNbAJ.KF1T99fI3t3Y8BdLMlt njjUuFIVyLIQ0J5lRfTYOY4aq8UPHPjaCureaGV0cs4.vt31RxlOFrh4lI.T ET5cue6rfRpuwPbjEgRW9o.JAuwZ932otNny1MxgoTW8y_ROvSBXJuXxqITf sTBuKWRkJs7jFi6URY4MIaGP_3vbSLEEvgo69ch_RRtA- X-Yahoo-SMTP: opAkk_CswBAce_kJ3nIPlH80cJI- In-reply-to: <20161102045925.GA6763@fujitsu.shahaf.local2> From: Oliver Kiddle References: <20161005080921.GB26647@raspi> <161005101938.ZM12590@torch.brasslantern.com> <20161102045925.GA6763@fujitsu.shahaf.local2> To: zsh-workers@zsh.org Subject: Re: Bug in ZSH's vi emulation MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11718.1478105483.1@hydra.kiddle.eu> Date: Wed, 02 Nov 2016 17:51:23 +0100 Message-ID: <11719.1478105483@hydra.kiddle.eu> Daniel Shahaf wrote: > > On Oct 5, 10:09am, Ghjuvan' Lacambre wrote: > > } 'd.' isn't a valid action as '.' is not a valid motion, yet 'd.' is > > } recorded as the last action called. When using '.', 'd.' will > > } recursively call itself > Is it simply a matter of setting vichgbufptr to 0 if getvirange() > returns -1? I've tried that; it fixes the problem and passes > tests. Not really. If we want a quick fix for 5.3 then either that or checking virangeflag at the top of virepeatchange will do the job. For a correct vi compatible fix, anything that causes the widget - vi-delete or whatever to return failure should abort the vi change and the previous value of vichgbuf should be restored. So most occurences of vichgflag = 0 could change to call a new endvichange() which would do the restore. Or that might be factored out into the caller. I'm also pondering the interaction with user-defined widgets. Note that from vi, with a key mapping of :nmap \d dwdw Then, \d followed by dot will remove three words not four. dot only repeats the final change. In practice this isn't especially useful so things like the repeat.vim plugin exist. I'm not sure that we should even strive for vi compatibility here but I think we're missing some logic in cases where calls to startvichange occur as part of a user-defined widget. 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. Oliver