From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14546 invoked by alias); 7 Dec 2016 12:45:31 -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: 40118 Received: (qmail 6922 invoked from network); 7 Dec 2016 12:45:31 -0000 X-Qmail-Scanner-Diagnostics: from nm34-vm8.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.122):SA:0(0.0/5.0):. Processed in 1.482746 secs); 07 Dec 2016 12:45:31 -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, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,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.122 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1481114392; bh=wnuHWeKvt9gPtpoFNYTGQbIbowI7ukuIPIeVa6JOfEA=; h=In-reply-to:From:References:To:Subject:Date:From:Subject; b=jjxopaBf5z5JEPunUZeR47YGux0Oi3haTa4uxNvspjsJN4LroiMfFIOnNAIwWwIHrqFq/Vp8CseUYipG9lpCxUFaGPCL9rPkSPBUc1ZB3xkMma8nO0cytTzP0qrJchgI57D3Fp0hoCAtvtAaFmlx1KFGWzIOsjThPs+CZBoV3BesGvATogab2Iv3hmlSOjq8qS11ryFwfnY0ogM6GPZvCfroiXOL3DlUwYsj+YFcASDTSysf4RQvHvRrMivfFHxYlb/JlGoNAIBSfNdDx9CbyWupVWK8r/6+gzW2s4c+jE/RQZVUjtT5nerLv+hS0hUZNk9w1bT23X2aG85Q80dNAw== X-Yahoo-Newman-Id: 121762.60198.bm@smtp138.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: v9853pcVM1mtmXJZeQc7KQZqGH0TdsbhL9NETDMe9FOw9I4 O1rGvxioo_abLRldhF04rh9Iep3WKXCxHk.lGe56uCs7ik7tuZjoS5d_hPlP OpdxUY_e9EeRb3kvMxdv4GM1gYm31DiYcs7k0KqEuR.0a444gIX2vd7S54jk xVagMGsOYck2TazO6mvTxCN.t5S8yNuKQqR3bPvPwdAXF5HSL4r9AtGpxAKN KDEvpR1sXYUv9.gOIxsUXQrNJJZMogoVlpF8SbmGl9vok_JI1N9nJl_eTXvx yiEtC9fTpQBS0R5ey5fNOtExURPW3o6cuaYYDPW7JTTVkgN32Y6rGM2lFR8G gYOnIrWMBkuoqRuoV4Lsw.PaPgg6NVyU2qVkqrH6ougAgMzbMRnKwFij3PI7 PO77dPdAu5Q_5UKjNRKRYB.UB7Nr7oV3qUzGkKmAox4JT.hkQoLEtAreCr6H JeLcxJYSt0R2hRuHK8i5LG8boee0Xh4Gov40p_7RSj5nOuwfJZb28py11_Xq aaRrhz2b783ELW4V1K3qyRT3CrIt0fBq66Le8gk4V X-Yahoo-SMTP: opAkk_CswBAce_kJ3nIPlH80cJI- In-reply-to: From: Oliver Kiddle References: To: Zhiming Wang , Zsh hackers list Subject: Re: Regression in bracketed-paste-magic (not in 5.2, but affects 5.3's test releases) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13853.1481114391.1@hydra.kiddle.eu> Date: Wed, 07 Dec 2016 13:39:51 +0100 Message-ID: <13854.1481114391@hydra.kiddle.eu> Bart wrote: > This probably indicates a problem with undo-point handling around history > search, which has been a sticky wicket in the past. The patch you cite > replaced b-p-m's internal handling of $BUFFER with reliance on the undo > mechanism. In this particular case, the problem is that fc -p doesn't result in a call to zle's remember_edits(). remember_edits() updates the table of history entries for the current line. The edit associated with doing BUFFER= CURSOR=1 is thus lost. So when it does the undo, the line is first restored when the history line is reselected and then the contents are duplicated when the effect of clearing $BUFFER is undone. Unfortunately, the ZLE_CMD_SET_HIST_LINE callback happens after this history line is updated so we can't call remember_edits() from there. We could simply add another similar hook and call it earlier. What I would suggest for 5.3 is the patch below. fc -p doesn't trigger handleundo() either so by moving split-undo above the clearing of the buffer, we ensure that the edit is missed by both the undo and history. Referencing $UNDO_CHANGE_NO does force handleundo() so the downside of this is that UNDO_LIMIT_NO will allow an undo back to the state before clearing $BUFFER. If you're wondering why I suggest this rather than adding a hook to call remember_edits(), it is because, for a proper post-5.3 patch, fc -p wouldn't actually change the current history line. The only thing that changes is the history number. If history internals use the Histent to identify history entries then undo wouldn't see fc -p/-P as a change of history line and we could kill the associated bugs. I've got some unfinished work on this on a git branch if someone's interested to play with it. But for now, calling fc -p in a widget is going to get you undo oddities. I don't use bracketed-paste-magic so would appreciate if someone else could do some testing and make the call on what should go into 5.3. Oliver diff --git a/Functions/Zle/bracketed-paste-magic b/Functions/Zle/bracketed-paste-magic index fb584d5..c3cc8b6 100644 --- a/Functions/Zle/bracketed-paste-magic +++ b/Functions/Zle/bracketed-paste-magic @@ -151,10 +151,10 @@ bracketed-paste-magic() { integer bpm_mark=$MARK bpm_region=$REGION_ACTIVE integer bpm_numeric=${NUMERIC:-1} integer bpm_limit=$UNDO_LIMIT_NO bpm_undo=$UNDO_CHANGE_NO - BUFFER= - CURSOR=1 zle .split-undo UNDO_LIMIT_NO=$UNDO_CHANGE_NO + BUFFER= + CURSOR=1 fc -p -a /dev/null 0 0 if [[ $bmp_keymap = vicmd ]]; then zle -K viins