From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14226 invoked by alias); 12 Jun 2015 19:12:53 -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: 35452 Received: (qmail 16941 invoked from network); 12 Jun 2015 19:12:50 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.0 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version:content-type; bh=iQdg1yTkz5AFHYCX1Uibip1QoVK71aKP0vLpKyyu7Rg=; b=W2Eu1Jb9kLfbt7uohMwbh9lH9QX/58Nv6yDRWcPFybAWF3HVxAaULtc2eak127ACjv MmGCBFGmDgf8HY1A3++kUBAdY1xRKK4uayrMRrxnbRrA61l3og59SsFt+Hrqaq/EEBrC Q/JE66BRpzCfoRJ32JmKX9fesB8r0FuPr20oPMCW9E9UGUQaN0Hd0Se0ggrFZq9Qc1lF 4trD44xAzmgiWCiireEWlvKv42YUmZlYwfvjrtuB/vIJ/ATGWU6QaYut1sXsuY0j/3Oa mHl18F2IPzTqYnsaBDgA5qhcf/W3GtuYc5gJR5t5byHJUFVz2bcd2cCC1hHPBnI6qgK7 OufA== X-Gm-Message-State: ALoCoQnFOkVDS25cNjh0/U5jhFTxEhVNyMDWXGlXJcE1P3R0tpNzSuznw5hodqGJjLXPUrmDCQR3 X-Received: by 10.182.181.103 with SMTP id dv7mr13430006obc.25.1434136366488; Fri, 12 Jun 2015 12:12:46 -0700 (PDT) From: Bart Schaefer Message-Id: <150612121242.ZM789@torch.brasslantern.com> Date: Fri, 12 Jun 2015 12:12:42 -0700 In-Reply-To: <20150612091627.GA10815@ypig.lip.ens-lyon.fr> Comments: In reply to Vincent Lefevre "smart-insert-last-word bug in zsh 5.0.7" (Jun 12, 11:16am) References: <20150612091627.GA10815@ypig.lip.ens-lyon.fr> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: smart-insert-last-word bug in zsh 5.0.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Jun 12, 11:16am, Vincent Lefevre wrote: } Subject: smart-insert-last-word bug in zsh 5.0.7 } } ypig% autoload -U smart-insert-last-word } ypig% zle -N insert-last-word smart-insert-last-word } ypig% echo abc def } abc def } } echo [Esc].[Left][Backspace][Ctrl-e] [Esc]. } } The second [Esc]. should have given: } } echo df def[ ] } } like without smart-insert-last-word. So the problem here is that smart-insert-last-word is using the cursor position as a clue for whether it should start the search over, or look farther up the history. This is still true in 5.0.8. When you do [Esc].[Left][Backspace][Ctrl-e][Space] you change the line, but then return the cursor to its previous offset. smart-insert-last-word thinks this means it should pick up where it left off, because neither the history number nor the cursor position have changed. Now that we have UNDO_CHANGE_NO, that's probably a better way to track the state, but maybe someone can find a different problem with that? diff --git a/Functions/Zle/smart-insert-last-word b/Functions/Zle/smart-insert-last-word index 27b0849..5288c1d 100644 --- a/Functions/Zle/smart-insert-last-word +++ b/Functions/Zle/smart-insert-last-word @@ -47,13 +47,13 @@ setopt extendedglob nohistignoredups zle auto-suffix-retain # Not strictly necessary: -# (($+_ilw_hist)) || integer -g _ilw_hist _ilw_count _ilw_cursor _ilw_lcursor +# (($+_ilw_hist)) || integer -g _ilw_hist _ilw_count _ilw_changeno _ilw_lcursor integer cursor=$CURSOR lcursor=$CURSOR local lastcmd pattern numeric=$NUMERIC # Save state for repeated calls -if (( HISTNO == _ilw_hist && cursor == _ilw_cursor )); then +if (( HISTNO == _ilw_hist && UNDO_CHANGE_NO == _ilw_changeno )); then NUMERIC=$[_ilw_count+1] lcursor=$_ilw_lcursor else @@ -116,4 +116,4 @@ fi (( NUMERIC > $#lastcmd )) && return 1 LBUFFER[lcursor+1,cursor+1]=$lastcmd[-NUMERIC] -_ilw_cursor=$CURSOR +_ilw_changeno=$UNDO_CHANGE_NO