[gnu.bash.bug] Bash suggestion

davison@EDDIE.MIT.EDU (Wayne Davison) (01/14/90)

I've a suggestion for improving bash's history mechanism.  This method would
improve searching the history buffer using the emacs/vi commands by removing
all duplicate commands, yet still allow csh !-references to specific history
numbers (including relative offsets).  An additional suggestion allows the
repetition of a sequence of commands with ease.

What we want to accomplish is to appear to the emacs/vi searcher (e.g. Ctrl-R
AND Ctrl-P) that the history is a set of unique entries sorted with the most
recent entries at the end.  We can do this by searching the history for each
typed command, and "moving" the one possible exact match if found to the end.
If not found, we add the new unique command to the end.  This greatly improves
searching for prior commands, since we don't encounter the same command twice.
And, depending on the implementation, it might also save more commands since
we're only saving them each once.

However, for the !-reference user (like !-3, or !25), we must keep a list of
all of the commands in sequence.  And for the user that wants to repeat a
sequence of commands, we need to remember where we grabbed the last command
from, so we can grab the next one.

Here's an easy implementation for your current code that solves both problems:

Add a flag value to the HIST_ENTRY structure that we can set to the values of
REAL and DUPLICATE.  For all new or edited commands, a search would be made to
see if it was an exact match of a previously entered command (commands that
are recalled verbatim have a known match).  If we match, that entry's flag
field is set to DUPLICATE, and it is ignored in all emacs/vi command recalls.

Other optimizations could be made to save memory or to preferentially drop
duplicate commands from a stifled history space rather than old unique ones.
(One memory-saving example: use the DUPLICATE's line string when saving the
new entry, and only free the line on deletion when it is a REAL line.)

The "history_control=ignoredups" could turn this mode on, if you like (does
it do anything right now?  It doesn't work right here, and I couldn't find
anyone who made use of the history_control variable).  I would prefer having
this new mode as the default, and having the "history_control=ignoredups"
govern whether multiple consecutive entries of the same command would
increment the history number or not.

And, as promised, a special BONUS suggestion (for no extra charge!!):

Each time a command line is recalled from the buffer, save its history number.
Then add a command (C-X N?) that recalls the next command in sequence (which
would, of course, increment the recalled-from number).  As an alternative, you
could special-case the C-N command to perform this function when entered before
browsing the history buffer.

Thanks for listening!
-- 
Wayne Davison          \  /| / /| \/ /| /(_)         davison@drivax.UUCP
                      (_)/ |/ /\| / / |/  \          ...!amdahl!drivax!davison

allbery@NCoast.ORG (Brandon S. Allbery) (01/15/90)

As quoted from <9001140222.AA18573@drivax.dri> by think!ames!amdahl!drivax!davison@EDDIE.MIT.EDU (Wayne Davison):
+---------------
| Other optimizations could be made to save memory or to preferentially drop
| duplicate commands from a stifled history space rather than old unique ones.
| (One memory-saving example: use the DUPLICATE's line string when saving the
| new entry, and only free the line on deletion when it is a REAL line.)
+---------------

I can see potential problems, especially if one adds a new form of history
mechanism which might free up history space in some other order; an
alternative is to keep a usage count on the command and free it only when the
usage count drops to 0.  (I assume from "set history_control" that one can
have multiple history maintenance methods; and it is certainly worth
considering that one might have multiple modes for different ways of dealing
with single aspects of history control, or even a set-up like Emacs' major/
minor modes ("set history_control=(major minor ...)").

++Brandon
-- 
Brandon S. Allbery    allbery@NCoast.ORG, BALLBERY (MCI Mail), ALLBERY (Delphi)
      uunet!cwjcc.cwru.edu!ncoast!allbery ncoast!allbery@cwjcc.cwru.edu
*(comp.sources.misc mail to comp-sources-misc[-request]@backbone.site, please)*
*Third party vote-collection service: send mail to allbery@uunet.uu.net (ONLY)*

allbery@NCoast.ORG (Brandon S. Allbery) (01/15/90)

As quoted from <1990Jan15.001453.17288@NCoast.ORG> by allbery@NCoast.ORG (Brandon S. Allbery):
+---------------
| minor modes ("set history_control=(major minor ...)").
+---------------

Oops.  csh syntax.  "set history_control[0]=major history_control[1]=minor"?
Maybe ksh-style arrays need to be upgraded to support a "set multiple" feature
(I don't know if bash already has this or not).

++Brandon
-- 
Brandon S. Allbery    allbery@NCoast.ORG, BALLBERY (MCI Mail), ALLBERY (Delphi)
      uunet!cwjcc.cwru.edu!ncoast!allbery ncoast!allbery@cwjcc.cwru.edu
*(comp.sources.misc mail to comp-sources-misc[-request]@backbone.site, please)*
*Third party vote-collection service: send mail to allbery@uunet.uu.net (ONLY)*

arnold@audiofax.com (Arnold Robbins) (01/17/90)

In article <1990Jan15.001820.17413@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery) writes:
>Oops.  csh syntax.  "set history_control[0]=major history_control[1]=minor"?
>Maybe ksh-style arrays need to be upgraded to support a "set multiple" feature
>(I don't know if bash already has this or not).

If this is added, PLEASE use

	set -A foo val1 val2 ....

a la the ksh.  There is also set +A foo vall1 ... ; If I remember right,
+A does not unset the foo array first.  (set -A went into ksh at my
suggestion a while back...)
-- 
Arnold Robbins -- Senior Research Scientist - AudioFAX | Laundry increases
2000 Powers Ferry Road, #220 / Marietta, GA. 30067     | exponentially in the
INTERNET: arnold@audiofax.com	Phone: +1 404 933 7600 | number of children.
UUCP:	  emory!audfax!arnold	Fax:   +1 404 933 7606 |   -- Miriam Hartholz