From: Jun T <takimoto-j@kba.biglobe.ne.jp>
To: zsh-workers@zsh.org
Subject: Re: HIST_IGNORE_DUPS also ignores command lines that differ by a space between quotes
Date: Thu, 21 Mar 2024 18:41:08 +0900 [thread overview]
Message-ID: <8F03279D-3BFF-4612-92A6-78A2C119FBD3@kba.biglobe.ne.jp> (raw)
In-Reply-To: <CAH+w=7Y+i8cWYdOBfs2xMEqFFGf_4ucJFb-1ssRV3DZYUsXbVw@mail.gmail.com>
> 2024/03/21 14:36、Bart Schaefer <schaefer@brasslantern.com>のメール:
>
> On Wed, Mar 20, 2024 at 10:23 PM Jun T <takimoto-j@kba.biglobe.ne.jp> 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?
next prev parent reply other threads:[~2024-03-21 9:41 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-13 12:38 Vincent Lefevre
2024-03-14 5:13 ` Bart Schaefer
2024-03-15 12:53 ` Vincent Lefevre
2024-03-16 16:00 ` Bart Schaefer
2024-03-19 10:57 ` Vincent Lefevre
2024-03-19 11:08 ` Mikael Magnusson
2024-03-19 12:34 ` Vincent Lefevre
2024-03-20 17:46 ` Bart Schaefer
2024-03-20 17:48 ` Bart Schaefer
2024-03-20 23:48 ` Vincent Lefevre
2024-03-21 5:22 ` Jun T
2024-03-21 5:36 ` Bart Schaefer
2024-03-21 9:41 ` Jun T [this message]
2024-03-21 10:21 ` Vincent Lefevre
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8F03279D-3BFF-4612-92A6-78A2C119FBD3@kba.biglobe.ne.jp \
--to=takimoto-j@kba.biglobe.ne.jp \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).