Zsh Mailing List Archive
Messages sorted by:
Re: Proposed history improvements
- X-seq: zsh-workers 14292
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxx
- Subject: Re: Proposed history improvements
- Date: Thu, 10 May 2001 07:04:13 +0000
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <Pine.LNX.4.30.0105091518040.11301-100000@xxxxxxxxxxxxxxx> <E14xhFs-0006K9-00@xxxxxxxxxxxxxxxxxx>
On May 9, 3:45pm, Wayne Davison wrote:
} 1. I have gotten in the habit of prefixing certain commands with a space
} that I don't want cluttering up my history.
I've never used hist_ignore_space because I frequently copy-and-paste
commands and I dislike having to be careful about whether I grab any
leading whitespace in the process.
I'd much rather decide after the fact that I didn't want that command
put into the history; for example, I'd expunge all commands involving
typographical errors as soon as I'd had a chance to retrieve them and
fix the error, so that correct commands are never pushed out of the
history file by mistaken ones.
} My change makes an ignored command stick around just until the next
} command is typed.
This is a step in the right direction, at least.
} Do you think something like this should require a separate option?
No, I don't think it needs an option ... I think it should have worked
like this all along.
On May 10, 4:36am, Zefram wrote:
} Subject: Re: Proposed history improvements
} Wayne Davison wrote:
} >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. [...] 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.
} Or probably a better way would be to have a virtual associative array
} giving this importance number for each history element [...]
I agree that the proposed "deprecate" options are getting a bit complex,
and that some sort of shell-code solution seems preferable (this assoc
array suggestion would even let me implement deprecate-ex-post-facto).
With the assoc, we could avoid calling a function every time the history
is modified, and simply fix it up by assigning directly to the parameter
from precmd, which is a nice safe time and place to do it with respect
to other commands the shell is executing.
We'd need a better way to get at the current and previous event numbers,
though. (Have a look at the hack I did in zsh-workers/10996.)
} Actually almost the whole history mechanism *could* be moved out of
} the C [a]nd into shell code.
This would take quite a lot of work; emulating linked lists and rings
in shell code is messy at best.
(13.5% of all zsh options are related to history. 14.3% if Wayne goes
ahead with committing HIST_IMMEDIATE_DROP, on which I have no comment
except to say I think it's extraneous.)
Bart Schaefer Brass Lantern Enterprises
Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net
Messages sorted by: