Re: Proposed history improvements

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

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
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net