Re: HIST_IGNORE_DUPS also ignores command lines that differ by a space between quotes

[Jun T <takimoto-j@xxxxxxxxxxxxxxxxx>]

> 2024/03/21 14:36、Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>のメール:
> 
> On Wed, Mar 20, 2024 at 10:23 PM Jun T <takimoto-j@xxxxxxxxxxxxxxxxx> wrote:
>> 
>> I think HIST_IGNORE_DUPS would work as expected even without
>> HIST_REDUCCE_BLANKS if we use the information in chwords and
>> hist_ring->words, as in the patch below, for example.
> 
> Doesn't that require HIST_LEX_WORDS to be set to poplulate ->words
> when reading histfiles?

I think ->words is always populated; without HIST_LEX_WORDS it may
contain wrong info, but for HIST_IGNORE_DUPS only the last event in the
history file matters.
# If this is a problem, we may set uselex to true for the last event
# from the hist file, near line 2821 in hist.c, in function readhistfile().

> And further, would it not behave differently
> for "print -s" vs. "print -S"?

Sorry I can't understand this, but:

print -S ': "a b"'
and
print -s : '"a b"'
are equivalent.

print -s : "a b"
is different, but 

% print -s : "a b"
% history -1
 1025  : a b         # 'a b' is a single word
% echo !1025:1
echo a b
a b

This is quite confusing. With my patch, even with HIST_IGNORE_DUP,

% print -s : "a b"
% : a b
% history -2
 1028  : a b	# one arg
 1029  : a b	# two args

This may make already confusing situation more confusing.
Without my patch the event 1028 is overwritten by the
correct one (with two args); somewhat better than with my patch?
But anyway use of 'print -s' with args containing spaces is
best avoided, I think.

BUT:
Do we really need the option HIST_REDUCE_BLANKS? I mean, how about
making zsh behave always as if HIST_REDUCE_BLANKS is ON?
Are there any user who want to keep unnecessary spaces in history?
Or calling histreduceblanks() may slow down the interactive zsh?