From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16240 invoked by alias); 27 Jan 2014 16:29:10 -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: 32309 Received: (qmail 11058 invoked from network); 27 Jan 2014 16:29:05 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 From: Bart Schaefer Message-id: <140127082902.ZM19971@torch.brasslantern.com> Date: Mon, 27 Jan 2014 08:29:02 -0800 In-reply-to: <20140127124301.4144f2d9@pwslap01u.europe.root.pri> Comments: In reply to Peter Stephenson "Re: zle: vi mode: wrong undo handling on fresh lines" (Jan 27, 12:43pm) References: <20130923213014.15f97f9e@pws-pc.ntlworld.com> <3511.1390605547@thecus.kiddle.eu> <140125111530.ZM21792@torch.brasslantern.com> <20140127124301.4144f2d9@pwslap01u.europe.root.pri> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: zle: vi mode: wrong undo handling on fresh lines MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Jan 27, 12:43pm, Peter Stephenson wrote: } Subject: Re: zle: vi mode: wrong undo handling on fresh lines } } On Sat, 25 Jan 2014 11:15:30 -0800 } Bart Schaefer wrote: } > } > Yes, I think it's a bug that completion doesn't behave as if you've } > left and then re-entered insert mode. } } So presumably startvichange() needs calling somewhere else? I'm not sure that's exactly it, since we're already in insert mode ... } There is some interaction with completion in the top-level } docomplete() call: } } /* For vi mode, reset the start-of-insertion pointer to the beginning * } * of the word being completed, if it is currently later. Vi itself * } * would never change the pointer in the middle of an insertion, but * } * then vi doesn't have completion. More to the point, this is only * } * an emulation. */ That's kind of related, I think. A single undo should not cross over the insertion point, so if we've moved that, we should have started a new undo event. } Maybe there needs to be a hook from the outside world. Either that or (shudder) we need vi- wrapped versions of the completion widgets. } > Clearly more is needed to properly set up the vi-mode state at the start } > of the buffer. } } That kind of suggests there's some stuff startvitext() or } startvichange() ought to be doing already but isn't, but we've got away } with it somehow. OH! The problem seems to be that startvichange() always initializes vichgbuf[0] = lastchar, and lastchar is still the trailing '\r' from the previous command. Is it safe to initialize lastchar = 0 when we enter a new ZLE?