Re: HIST_IGNORE_DUPS ignores lines which differ by a different number of spaces

[Bart Schaefer <schaefer@brasslantern.com>]

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 <p.w.stephenson@ntlworld.com> 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.