Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Proposed history improvements
- X-seq: zsh-workers 14289
- From: Zefram <zefram@xxxxxxxx>
- To: Wayne Davison <wayned@xxxxxxxxxxxxxxxxxxxxx>
- Subject: Re: Proposed history improvements
- Date: Thu, 10 May 2001 04:36:44 +0100 (BST)
- Cc: Zsh Workers <zsh-workers@xxxxxxxxxxxxxx>
- In-reply-to: <Pine.LNX.4.30.0105091518040.11301-100000@xxxxxxxxxxxxxxx> from Wayne Davison at "May 9, 2001 03:45:29 pm"
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
Wayne Davison wrote:
> My change makes an ignored command stick around
>just until the next command is typed.
Nice.
> Do you
>think something like this should require a separate option?
Probably, but I don't see a problem with the option being on by default.
>2. I thought it would be cool if I could hint to the history system
>about which lines I consider more important. With HIST_DEPRECATE_SPACE
...
This bit is getting too complicated. Instead of having multiple
competing options (HIST_DEPRECATE_SPACE and HIST_EXPIRE_DUPS_FIRST --
where's HIST_DEPRECATE_DUPS for the opposite priority ordering?), let's
have some configurable shell code to decide how important each history
entry is. We can have a shell function that gets called whenever a
line is added to the history, which gets to reply a number saying how
important the line is. The effect of both HIST_DEPRECATE_SPACE and
HIST_EXPIRE_DUPS_FIRST being on can then be achieved by
function histimportance {
if [[ -n "${(k)history[(r)$1]}" ]]; then
REPLY=1
elif [[ "$1" == " "* ]]; then
REPLY=2
else
REPLY=3
fi
}
Or probably a better way would be to have a virtual associative array
giving this importance number for each history element, initialised
according to the existing options, and have a "histadded" function that
has the option to change this number for the current event or in fact
for any previous event (allowing duplicates to be expired oldest-first
instead of the newest-first that the above code does).
Other history stuff that could similarly be moved to shell code: deciding
whether a history line is to be stored at all (say, the "histadded"
function returns non-zero to say "don't add this to the history");
deciding whether a history line is to be saved in the history file
(another array, paralleling the `importance' one described above, or
an overloaded meaning for the importance array); possibly the history
file saving itself. Actually almost the whole history mechanism *could*
be moved out of the C nd into shell code.
-zefram
Messages sorted by:
Reverse Date,
Date,
Thread,
Author