From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18835 invoked by alias); 2 Nov 2016 04:59:36 -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: 39806 Received: (qmail 2192 invoked from network); 2 Nov 2016 04:59:36 -0000 X-Qmail-Scanner-Diagnostics: from out2-smtp.messagingengine.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(66.111.4.26):SA:0(0.0/5.0):. Processed in 0.564805 secs); 02 Nov 2016 04:59:36 -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=T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at daniel.shahaf.name does not designate permitted sender hosts) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= daniel.shahaf.name; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=VXyTiSomo9oVgpI 8DoqG9GI3NcE=; b=jJKVIZBWY6bt7E6E3Q0B7ab/pBa9ePxi+2MvCe7DfykzKXI 27PDL2k2YpiInqaqhplzuHrCpN71fm96dvWuM7ER+vFZlmhy4sGOQ1TqDbAZXngQ GDkqPhGGJg8WxPKUsHjlAQ9ckr37EBvQhKIHplT7GhZC1hs0tYvW5Q7kqeq4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=smtpout; bh=VXyTiSomo9oVgp I8DoqG9GI3NcE=; b=HbRHbZQpE/vccimZyH677IwU52MOA9Uk4bn/Brlgc/JO1x ToGh+C5ONBg3o0S6JWmrEnlMK7XZV9t/NNc0T84f/DqjPkfx3vF9Muq1U2Disykm 5Wgw1lI6APq7IJ0h8gmZFX5boTaQ7V95kT/pC9j11Bud4dRwhD+8FF2Aff/0Q= X-ME-Sender: X-Sasl-enc: zMaDe7XnZs6UPYrCemOYZl/5xGxutfelB7yCh48iyAVb 1478062767 Date: Wed, 2 Nov 2016 04:59:25 +0000 From: Daniel Shahaf To: zsh-workers@zsh.org Subject: Re: Bug in ZSH's vi emulation Message-ID: <20161102045925.GA6763@fujitsu.shahaf.local2> References: <20161005080921.GB26647@raspi> <161005101938.ZM12590@torch.brasslantern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <161005101938.ZM12590@torch.brasslantern.com> User-Agent: Mutt/1.5.23 (2014-03-12) Bart Schaefer wrote on Wed, Oct 05, 2016 at 10:19:38 -0700: > 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 > > Confirmed. > > Seems to be a problem with calling startvichange(1) before calling > getvirange(), so the input is captured as a change event whether it > succeeds or fails. Unfortunately, I'm not familiar enough with the > vi emulation code to see how to back out of startvichange(). 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. Also here's a docs patch with my understanding some related globals. diff --git a/Src/Zle/zle_vi.c b/Src/Zle/zle_vi.c index baa2064..2cddea7 100644 --- a/Src/Zle/zle_vi.c +++ b/Src/Zle/zle_vi.c @@ -47,10 +47,19 @@ int vilinerange; /* last vi change buffer, for vi change repetition */ +/* + * vichgbufsz: Allocated size of vichgbuf. + * vichgbufptr: Length in use. + * vichgflag: true whilst inputting a vi normal mode; causes it to be + * accumulated in vichgbuf, incrementing vichgbufptr. + */ + /**/ int vichgbufsz, vichgbufptr, vichgflag; /* + * The bytes that make up the current vi command. See vichgbuf* above. + * * Examination of the code suggests vichgbuf is consistently tied * to raw byte input, so it is left as a character array rather * than turned into wide characters. In particular, when we replay