From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23469 invoked by alias); 20 Apr 2013 03:01:25 -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: 31282 Received: (qmail 4843 invoked from network); 20 Apr 2013 03:01:23 -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 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <130419200113.ZM9865@torch.brasslantern.com> Date: Fri, 19 Apr 2013 20:01:13 -0700 In-reply-to: <20130419134238.7a8a05a3@pwslap01u.europe.root.pri> Comments: In reply to Peter Stephenson "Re: HIST_IGNORE_DUPS ignores lines which differ by a different number of spaces" (Apr 19, 1:42pm) References: <20130416170518.GD18872@xvii.vinc17.org> <20130418210411.3254ac63@pws-pc.ntlworld.com> <20130419134238.7a8a05a3@pwslap01u.europe.root.pri> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: HIST_IGNORE_DUPS ignores lines which differ by a different number of spaces MIME-version: 1.0 Content-type: text/plain; charset=us-ascii I haven't ever really dug into this code, and the last person who did so I think was probably Wayne when working on HIST_EXPIRE_DUPS_FIRST back in 1999 and 2002. It appears Zoltan did most of the work on the *DUPS* -related stuff even longer ago than that. With that caveat ... On Apr 19, 1:42pm, Peter Stephenson wrote: } Subject: Re: HIST_IGNORE_DUPS ignores lines which differ by a different nu } } On Thu, 18 Apr 2013 21:04:11 +0100 } Peter Stephenson wrote: } > My best guess is it's got something to do with freehistdata(), which } > appears to be the only way the hash table can affect the history ring. } } Revised theory: when the new node gets added, it retrieves the old node } (addhistnode() in hashtable.c). Because of the name mangling it } retrieves the previous line if that's the same up to (any, even } significant) white space, even if HIST_IGNORE_DUPS isn't set. (This is } what's bamboozling me the most.) The behavior is supposed to be that the most-recent previous command line is always retrievable verbatim, regardless of whether history is ignoring dups or even turned off entirely. So the editor behavior is as if HISTSIZE can never be less than 1, even though that line will never be saved anywhere when HISTSIZE=0. I vaguely recall from reading the discussions years back that this is implemented by pushing commands into the "real" history ring only when the *next* command is accepted, that is, there's some sort of purgatory where the single previous command goes to wait before being sent to heaven or hell by the arrival of a new command. Perhaps that gives some insight into what you're seeing in the code? } Because there's an old node (at all, } even if it doesn't match completely) it gets marked as HIST_DUP by } addhistnode(). Then logic elsewhere removes it. I would not be surprised to find that the HIST_DUP marker is set for two reasons: (1) so HIST_EXPIRE_DUPS_FIRST can work even when NO_HIST_IGNORE_DUPS (2) to implement HIST_FIND_NO_DUPS even when NO_HIST_IGNORE_DUPS } It's just occurred to me that while it might get *marked* with HIST_DUP } undconditionally, the logic to remove duplicates only kicks in if } HIST_IGNORE_DUPS is set. That might explain why NO_HIST_IGNORE_DUPS } works at all. Don't forget HIST_IGNORE_ALL_DUPS, too ... Sorry I can't be more helpful.