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

[Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>]

On Tue, 16 Apr 2013 19:05:18 +0200
Vincent Lefevre <vincent@xxxxxxxxxx> wrote:
> % setopt HIST_IGNORE_DUPS
> % echo " "
> % echo "  "
> 
> If I type the up arrow, I get
> 
>   echo "  "
> 
> as expected, but if I type the up arrow a second time, I get
> 
>   setopt HIST_IGNORE_DUPS
> 
> instead of
> 
>   echo " "
> 
> and:
> 
> % history
>     1  setopt HIST_IGNORE_DUPS
>     2  echo "  "

This turns out to be hard.  Fixing the basic comparison is
straightforward, and I did, but it turns out that's not good enough.
Then it gets complicated.  After the code has decided whether the line
is identical to the previous one or not, it gets added as a hash node to
the history table.  This has buried into it at quite a low level the
comparison function that compares lines ignoring white space.  I don't
quite understand how the hash business comes into it, given that the
basic point of hend() is to use the history ring and I can't actually
see anything ever being retrieved from the table.

The whole way history is stored in histtab apparently makes it
impossible to take account of white space --- even when retrieving a
node where the only information you've got is the name, which is what's
really stumped me, since the information about words within the line
isn't available at that point --- so unless someone can explain what's
going on here I'm stuck.

It's possible the hash table business is a red herring --- the
comparison behaviour ignoring all white space is present even when
HIST_IGNORE_DUPS isn't set --- and there's a problem somewhere else that
I haven't spotted, but I did confirm that my change caused the lines to
compare differently around line 1273 of hist.c, so it's something
subtle.

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.

pws