Wayne Davison wrote:
>The matching rule would allow more general command-name rules, plus
>line-oriented rules that name-oriented support don't allow.  For
>instance:  ignoring lines that are just 1 or 2 chars long; ignoring
>the make command unless it had an argument or was a part of a compound
>statement; ignoring the history command, but only if it is not a part
>of a compound statement (such as having its output piped into a
>script); ignoring lines that begin with whitespace (including tab)
>without having any extra alias-checking rules done; ignoring a lynx
>command that uses the -auth option; etc.
>
>The plus side is that a line-matching rule is much more flexible.  The
>down side is that a user has to understand complex patterns to be able
>to use it effectively.  Some good examples would get the casual user
>going, though.

Yeah, I was talking about something similar that could be used with
Bart's new smart-insert-last-word widget.  Seems like some common ability
to match and filter history would be useful in several situations.  Sort of
a regex for command history... 8)

Another thing I would use is a "soft" or "fuzzy" history mechanism.  For
example, I would really like to be able to intercept a "!$" history option
and replace it with a call to smart-insert-last-word (w/command line matching).
Or the ability to intercept other history calls like !* or !!.  It seems like
it would be useful to have an option that would allow us to play with this
history mechanism, so it's a little more DWIM.

-FR

__________________________________________________
Do You Yahoo!?
Get Yahoo! Mail – Free email you can access from anywhere!
http://mail.yahoo.com/