Re: PATCH: zsh-3.1.5-pws-6: bash-style completion

Re: PATCH: zsh-3.1.5-pws-6: bash-style completion

[Sven Wischnowsky]

Peter Stephenson wrote:

> Sven Wischnowsky wrote:
> > > I've also been having strange effects when combining all this with:
> > >   compctl -M 'm:{a-z}={A-Z}' 'r:|[.,_-]=* r:|=*'
> > 
> > Hm, I haven't found any unusual behavior here, so I guess, I need an
> > example.
> 
> The following alone works for me, in the Src directory of the
> distribution where z<TAB> is ambiguous.
> 
> % zsh -f
> % compctl -M 'm:{a-z}={A-Z}' 'r:|[.,_-]=* r:|=*'
> % echo z<TAB>
>        ^cursor is now over the z.
> 
> Now delete the line with ^U, enter `compctl -M', and try the same
> example again, and the shell dies.

The patch below fixes both of these. I'll write an extra comment about 
the positioning of the cursor.

> > I have only a bash-2.01.1 here but that version shows the behavior to
> > list the matches only on the third TAB: 1) insert unambiguous prefix,
> > 2) do nothing, 3) show list. If the unambiguous prefix was completely
> > typed (not automatically inserted), it first does nothing and shows
> > the list on the second TAB. So I'd vote for removing the test, see the 
> > patch below which also fixes a typo in your patch. Otherwise using
> > BASHAUTOLIST will be the same as LISTAMBIGUOUS+AUTOLIST if the
> > unambiguous prefix had to be automatically inserted.
> 
> That's fine by me; you can unset LISTAMBIGUOUS to get the other
> behaviour.  The patch changes the documentation.
> 
> However, I'm having problems with LISTAMBIGUOUS when RECEXACT is set,
> because `am' then gets set a few lines above that, apparently even if
> there isn't an exact completion, and the chunk in question is skipped.
> Any ideas?

Yes, there was a problem with listambiguous showing the list too
early. This was caused by a wrong calculation in ainfo->prerest. I've
changed that to collect the minimum match length and compare it to
what is inserted.

Another problem I can see is the combination of menucomplete and
bashautolist. Here the list is never shown since we never get to the
second tab. Maybe we should just document this.

Bye
 Sven

--- oos/Zle/zle_tricky.c	Fri Feb  5 08:49:33 1999
+++ Src/Zle/zle_tricky.c	Fri Feb  5 09:26:42 1999
@@ -223,7 +223,7 @@
 
 struct aminfo {
     int cpl, csl, icpl, icsl;	/* common prefix/suffix lengths           */
-    int prerest;		/* minimum prefix rest                    */
+    int minlen;			/* minimum match length                   */
     int suflen;			/* minimum suffix length                  */
     Cmatch firstm;		/* the first match                        */
     char *pprefix;		/* common part of the -P prefixes         */
@@ -1824,9 +1824,17 @@
     pl += brpl;
 
     i = cs - wb;
+    if (pl >= 0 && i >= pl && brbeg && *brbeg) {
+	inststrlen(brbeg, 1, -1);
+	pl = -1;
+	hb = 1;
+    }
+    if (sl >= 0 && i >= sl && brend && *brend) {
+	inststrlen(brend, 1, -1);
+	sl = -1;
+	hb = 1;
+    }
     while (l) {
-	if (d < 0 && (l->flags & CLF_DIFF))
-	    d = cs;
 	if (m < 0 && (l->flags & (CLF_MISS | CLF_SUF)) == (CLF_MISS | CLF_SUF))
 	    m = cs;
 	if (l->flags & CLF_MID) {
@@ -1840,6 +1848,8 @@
 	} else {
 	    inststrlen(l->line, 1, l->llen);
 	}
+	if (d < 0 && (l->flags & CLF_DIFF))
+	    d = cs;
 	if (m < 0 && (l->flags & CLF_MISS))
 	    m = cs;
 	i += l->llen;
@@ -2556,8 +2566,8 @@
 		    sl = strlen(s);
 		}
 		if (!ms && ai->firstm) {
-		    if ((i = pfxlen(ai->firstm->str, s)) < ai->prerest)
-			ai->prerest = i;
+		    if (sl < ai->minlen)
+			ai->minlen = sl;
 		    if ((i = sfxlen(ai->firstm->str, s)) < ai->suflen)
 			ai->suflen = i;
 		}
@@ -2823,8 +2833,8 @@
     if (!test)
 	return;
     if (!ms && !ispattern && ai->firstm) {
-	if ((test = sl - pfxlen(ai->firstm->str, s)) < ai->prerest)
-	    ai->prerest = test;
+	if (sl < ai->minlen)
+	    ai->minlen = sl;
 	if ((test = sfxlen(ai->firstm->str, s)) < ai->suflen)
 	    ai->suflen = test;
     }
@@ -3452,12 +3462,13 @@
 	    ms.next = NULL;
 	    ms.matcher = m->matcher;
 	    mstack = &ms;
-	}
+	} else
+	    mstack = NULL;
 	ainfo = (Aminfo) hcalloc(sizeof(struct aminfo));
 	fainfo = (Aminfo) hcalloc(sizeof(struct aminfo));
 
-	ainfo->prerest = ainfo->suflen = 
-	    fainfo->prerest = fainfo->suflen = 10000;
+	ainfo->minlen = ainfo->suflen = 
+	    fainfo->minlen = fainfo->suflen = 10000;
 	ainfo->noipre = fainfo->noipre= 1;
 
 	freecl = NULL;
@@ -5471,7 +5482,7 @@
 	 * on the next call to completion the inserted string would be     *
 	 * taken as a match and no menu completion would be started.       */
 
-	if (isset(RECEXACT) && !lc && !ainfo->prerest)
+	if (isset(RECEXACT) && !lc && ps && ainfo->minlen == strlen(ps))
 	    am = 1;
 
 	/*

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: PATCH: zsh-3.1.5-pws-6: bash-style completion

[Peter Stephenson]

Sven Wischnowsky wrote:
> The patch below fixes both of these. I'll write an extra comment about 
> the positioning of the cursor.

thanks.

> Another problem I can see is the combination of menucomplete and
> bashautolist. Here the list is never shown since we never get to the
> second tab. Maybe we should just document this.

I realised this, I didn't mention it because I thought it was
obvious.  That's a very bad assumption in zsh.

--- Doc/Zsh/options.yo.2t3	Fri Feb  5 10:11:35 1999
+++ Doc/Zsh/options.yo	Fri Feb  5 10:16:00 1999
@@ -157,7 +157,9 @@
 completion function is called twice in succession.  This takes
 precedence over tt(AUTO_LIST).  The setting of tt(LIST_AMBIGUOUS) is
 respected.  If tt(AUTO_MENU) is set, the menu behaviour will then start
-with the third press.
+with the third press.  Note that this will not work with
+tt(MENU_COMPLETE), since repeated completion calls immediately cycle
+through the list in that case.
 )
 pindex(BEEP)
 cindex(beep, enabling)

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Re: PATCH: zsh-3.1.5-pws-6: bash-style completion

[Sven Wischnowsky]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2962 bytes --]


Here is the comment on completion-matching and cursor-positioning.

Peter Stephenson wrote:

> % zsh -f
> % compctl -M 'm:{a-z}={A-Z}' 'r:|[.,_-]=* r:|=*'
> % echo z<TAB>
>        ^cursor is now over the z.

In a certain sense, this is correct. The matching code has to deal
with to possible differences between what was on the line and the
matches: character differencs and substrings that appear in the
match(es), but not on the line. The rule used is to position the
cursor preferably at a position where characters are missing and, if
there are no such places, to position the cursor on the first
character difference so that the user can type ^D, insert the wanted
character and type tab. My patch that `fixed' this places the cursor
after the first differing character (so that backspace-char-tab can be 
used, which is easy enough to type, too).

Now, some people may already have noticed that the code that inserts
this unambiguous string into the command line isn't very powerful. To
be more exact: it has problems with those parts of the matches that
differ from match to match and that don't have a corresponding part
typed by the user. Examples:

- With -M 'm:{a-z}={A-Z}' completing an empty prefix with the two 
  possible matches `Foobar' and `foobaz' the code should insert
  `fooba' with the cursor after it. With possible matches `Foobar' and
  `foobar' it should insert `foobar' with the cursor after
  (previously: on) the `f'. This could be done by checking if a match
  matches all the other matches. Doing this fast enough is already not 
  that easy.
- This also wouldn't help much. Consider the same match specification
  with the matches `Foobar' and `fooBar'. Here the code would have to
  check parts of matches against each other. Doing so with no hint
  where these parts are (i.e. chunks of characters that should be tested
  as groups), is already quite complicated.
- This gets worse if there are match specifications with different
  lengths for the line/word-patterns. With -M 'm:{a-z}={A-Z} m:ß=SS'
  and the matches `MASSE' and `Maße' we would want `Maße' to be inserted.
- All these examples were `simple' in the sense that the parts of the
  string to insert appeared in the matches, but this need not be. With
  -M 'm:{a-z}={A-Z} m:{aou}e={äöü}' and the matches `MUEHE' and `Mühe' 
  we'd like to have `Muehe' inserted where the `ue' was derived only
  from looking at the matching specification. (And in a German
  language environment a matching specification like the one given may 
  really be used - for `ä' you need to type four keys.)

Of course all this can be intermixed with partial word completion etc.

So, I'll have to think about all this some more to find out what can
be done without too much effort and without being too slow. I'll be
gratefull for every opinion, suggestion, and comment I'll get about
all this.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: PATCH: zsh-3.1.5-pws-6: bash-style completion

[Bart Schaefer]

On Feb 4,  3:12pm, Peter Stephenson wrote:
} Subject: Re: PATCH: zsh-3.1.5-pws-6: bash-style completion
}
} However, I'm having problems with LISTAMBIGUOUS when RECEXACT is set,
} because `am' then gets set a few lines above that, apparently even if
} there isn't an exact completion, and the chunk in question is skipped.

Ah, yes, that's Sven's patch from zsh-workers/4148.  Previously when an
ambigous prefix partially-completed to an exact prefix, the next TAB
would simply accept that rather than proceeding into AUTOMENU.  After
4148, zsh "remembers" that the prefix was produced by completion, not
by having been typed, and therefore treats it as still ambiguous.

} Any ideas?

Perhaps it just needs to read

	am = !isset(BASHAUTOLIST);

instead of

	am = 1;

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: PATCH: zsh-3.1.5-pws-6: bash-style completion

[Dag-Erling Smorgrav]

Sven Wischnowsky wrote:
> Peter Stephenson wrote:
> > We seem to have this discussion every week.  It's not like bash,
> > because bash only shows the list on the *second* tab, and zsh can't
> > currently do that.
> I *know* that the thing I suggested shows behavior unlike bash. I was
> referring to the patch he sent which (as far as I can see, without
> testing it) should behave like LISTAMBIGUOUS plus AUTOLIST.

The patch I sent behaves like bash, i.e. shows the list on the second
tab. My first attempt didn't (I ran docomplete(COMP_COMPLETE) once,
*then* docomplete(COMP_LIST_COMPLETE) if lastambig was non-zero,
instead of running docomplete(COMP_COMPLETE) only if lastambig was
zero) but the one I sent does.

I haven't tried LIST_AMBIGUOUS + AUTO_LIST, so I can't comment on
whether or not my patch behaves like that.

DES (who ended up subscribing to -workers anyway)
-- 
Dag-Erling Smorgrav - des@flood.ping.uio.no

Re: PATCH: zsh-3.1.5-pws-6: bash-style completion

[Peter Stephenson]

Sven Wischnowsky wrote:
> > I've also been having strange effects when combining all this with:
> >   compctl -M 'm:{a-z}={A-Z}' 'r:|[.,_-]=* r:|=*'
> 
> Hm, I haven't found any unusual behavior here, so I guess, I need an
> example.

The following alone works for me, in the Src directory of the
distribution where z<TAB> is ambiguous.

% zsh -f
% compctl -M 'm:{a-z}={A-Z}' 'r:|[.,_-]=* r:|=*'
% echo z<TAB>
       ^cursor is now over the z.

Now delete the line with ^U, enter `compctl -M', and try the same
example again, and the shell dies.

> I have only a bash-2.01.1 here but that version shows the behavior to
> list the matches only on the third TAB: 1) insert unambiguous prefix,
> 2) do nothing, 3) show list. If the unambiguous prefix was completely
> typed (not automatically inserted), it first does nothing and shows
> the list on the second TAB. So I'd vote for removing the test, see the 
> patch below which also fixes a typo in your patch. Otherwise using
> BASHAUTOLIST will be the same as LISTAMBIGUOUS+AUTOLIST if the
> unambiguous prefix had to be automatically inserted.

That's fine by me; you can unset LISTAMBIGUOUS to get the other
behaviour.  The patch changes the documentation.

However, I'm having problems with LISTAMBIGUOUS when RECEXACT is set,
because `am' then gets set a few lines above that, apparently even if
there isn't an exact completion, and the chunk in question is skipped.
Any ideas?

--- Doc/Zsh/options.yo.2t2	Thu Feb  4 11:45:49 1999
+++ Doc/Zsh/options.yo	Thu Feb  4 15:06:20 1999
@@ -155,9 +155,9 @@
 item(tt(BASH_AUTO_LIST))(
 On an ambiguous completion, automatically list choices when the
 completion function is called twice in succession.  This takes
-precedence over tt(AUTO_LIST) and tt(LIST_AMBIGUOUS).  If
-tt(AUTO_MENU) is set, the menu behaviour will then start with the
-third press.
+precedence over tt(AUTO_LIST).  The setting of tt(LIST_AMBIGUOUS) is
+respected.  If tt(AUTO_MENU) is set, the menu behaviour will then start
+with the third press.
 )
 pindex(BEEP)
 cindex(beep, enabling)
@@ -497,10 +497,12 @@
 cindex(ambiguous completion)
 cindex(completion, ambiguous)
 item(tt(LIST_AMBIGUOUS))(
-This option works when tt(AUTO_LIST) is also set.  If there is an
-unambiguous prefix to insert on the command line, that is done without
-a completion list being displayed; in other words, auto-listing
-behaviour only takes place when nothing would be inserted.
+This option works when tt(AUTO_LIST) or tt(BASH_AUTO_LIST) is also
+set.  If there is an unambiguous prefix to insert on the command line,
+that is done without a completion list being displayed; in other
+words, auto-listing behaviour only takes place when nothing would be
+inserted.  In the case of tt(BASH_AUTO_LIST), this means that the list
+will be delayed to the third call of the function.
 )
 pindex(LIST_BEEP)
 cindex(beep, ambiguous completion)
--- Src/Zle/zle_tricky.c.2t2	Thu Feb  4 14:51:56 1999
+++ Src/Zle/zle_tricky.c	Thu Feb  4 15:02:28 1999
@@ -5479,11 +5479,7 @@
 	 * if the completion is completely ambiguous') is set, and some    *
 	 * prefix was inserted, return now, bypassing the list-displaying  *
 	 * code.  On the way, invalidate the list and note that we don't   *
-	 * want to enter an AUTO_MENU imediately.                          *
-	 *                                                                 *
-	 * We don't do this when BASH_AUTO_LIST is set, because that would *
-	 * mean you only got a completion list the third time you hit tab  *
-	 * (or whichever key).                                             */
+	 * want to enter an AUTO_MENU imediately.                          */
 	if(isset(LISTAMBIGUOUS) && !am &&
 	   (ics != cs || (ainfo->suflen && !atend))) {
 	    invalidatelist();


-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Re: PATCH: zsh-3.1.5-pws-6: bash-style completion

[Sven Wischnowsky]

Peter Stephenson wrote:

> I've also been having strange effects when combining all this with:
>   compctl -M 'm:{a-z}={A-Z}' 'r:|[.,_-]=* r:|=*'
> but I haven't tracked it down (and it's there anyway, I just normally
> use menu completion so hadn't noticed).  I think there may be a
> problem with `compctl -M' on its own, too, since I got a crash after
> that once.

Hm, I haven't found any unusual behavior here, so I guess, I need an
example.


>From the patch in do_ambiguous():

>	 * We don't do this when BASH_AUTO_LIST is set, because that would *
>	 * mean you only got a completion list the third time you hit tab  *
>	 * (or whichever key).                                             */
> 	if(isset(LISTAMBIGUOUS) && !isset(BASHAUTOLIST) && !am &&

I have only a bash-2.01.1 here but that version shows the behavior to
list the matches only on the third TAB: 1) insert unambiguous prefix,
2) do nothing, 3) show list. If the unambiguous prefix was completely
typed (not automatically inserted), it first does nothing and shows
the list on the second TAB. So I'd vote for removing the test, see the 
patch below which also fixes a typo in your patch. Otherwise using
BASHAUTOLIST will be the same as LISTAMBIGUOUS+AUTOLIST if the
unambiguous prefix had to be automatically inserted.

Bye
 Sven

--- Src/Zle/zle_tricky.c.old	Thu Feb  4 14:53:53 1999
+++ Src/Zle/zle_tricky.c	Thu Feb  4 14:59:31 1999
@@ -303,7 +303,7 @@
     else {
 	if (lastambig == 1 && isset(BASHAUTOLIST) && !usemenu && !menucmp) {
 	    docomplete(COMP_LIST_COMPLETE);
-	    lastambig == 2;
+	    lastambig = 2;
 	} else
 	    docomplete(COMP_COMPLETE);
     }
@@ -5484,7 +5484,7 @@
 	 * We don't do this when BASH_AUTO_LIST is set, because that would *
 	 * mean you only got a completion list the third time you hit tab  *
 	 * (or whichever key).                                             */
-	if(isset(LISTAMBIGUOUS) && !isset(BASHAUTOLIST) && !am &&
+	if(isset(LISTAMBIGUOUS) && !am &&
 	   (ics != cs || (ainfo->suflen && !atend))) {
 	    invalidatelist();
 	    lastambig = 0;

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: PATCH: zsh-3.1.5-pws-6: bash-style completion

[Sven Wischnowsky]

Peter Stephenson wrote:

> Sven Wischnowsky wrote:
> > I don't have a 3.0.5, so I couldn't try the patch. But as far as I can 
> > see, this should behave like normal completion with `setopt AUTOLIST'
> > and `setopt LISTAMBIGUOUS'.
> 
> We seem to have this discussion every week.  It's not like bash,
> because bash only shows the list on the *second* tab, and zsh can't
> currently do that.

I *know* that the thing I suggested shows behavior unlike bash. I was
referring to the patch he sent which (as far as I can see, without
testing it) should behave like LISTAMBIGUOUS plus AUTOLIST.

> Nor do I think it's fair to rely on the new
> completion to try to get this behaviour.

That's right.

> ...
>
> I've also been having strange effects when combining all this with:
>   compctl -M 'm:{a-z}={A-Z}' 'r:|[.,_-]=* r:|=*'
> but I haven't tracked it down (and it's there anyway, I just normally
> use menu completion so hadn't noticed).  I think there may be a
> problem with `compctl -M' on its own, too, since I got a crash after
> that once.

I'll look into this.


Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

PATCH: zsh-3.1.5-pws-6: bash-style completion

[Peter Stephenson]

Sven Wischnowsky wrote:
> I don't have a 3.0.5, so I couldn't try the patch. But as far as I can 
> see, this should behave like normal completion with `setopt AUTOLIST'
> and `setopt LISTAMBIGUOUS'.

We seem to have this discussion every week.  It's not like bash,
because bash only shows the list on the *second* tab, and zsh can't
currently do that.  Nor do I think it's fair to rely on the new
completion to try to get this behaviour.

It's so often requested by bash converts --- it seems to be the first
thing they noticed --- and it's not so hard to do, along the lines of
the 3.0.5 patch, and it's a good deal shorter than most of the recent
zle changes, so I would suggest simply doing it.  The following is a
suggestion for 3.1.5: it probably won't work in 3.0.5 without quite
major surgery, though it should be relatively straightforward since
the algorithms in question haven't changed as far as I know.

However, it's a bit problematic making it a function, since you might
want that behaviour with complete-word, expand-or-complete or
expand-or-complete-prefix (those are the three I've tracked down,
anyway).  So I've made it an option, called BASH_AUTO_LIST.  It takes
precedence over AUTO_LIST and LIST_AMBIGUOUS:  the reason
for that is that those are now set by default, so this provides the
simplest way for the user to change the default behaviour (without
having to decode lines like
  noautolist            off
to invert the double negative).

Note the behaviour when combined with AUTO_MENU:  one tab, complete
unambiguous part if any; two tabs, show list; three tabs, start
cycling through completions.

I've done basic testing on this, but with all the possible options I
can't claim everything's OK.

I only just discovered quite how LIST_AMBIGUOUS works, so I added to
the manual entry.

I've also been having strange effects when combining all this with:
  compctl -M 'm:{a-z}={A-Z}' 'r:|[.,_-]=* r:|=*'
but I haven't tracked it down (and it's there anyway, I just normally
use menu completion so hadn't noticed).  I think there may be a
problem with `compctl -M' on its own, too, since I got a crash after
that once.

--- Doc/Zsh/options.yo.2tab	Thu Feb  4 11:12:16 1999
+++ Doc/Zsh/options.yo	Thu Feb  4 11:45:49 1999
@@ -150,6 +150,15 @@
 list, if it contains no `tt(|)', `tt(LPAR())' or (if special) `tt(~)'
 characters.  See noderef(Filename Generation).
 )
+pindex(BASH_AUTO_LIST)
+cindex(completion, listing choices, bash style)
+item(tt(BASH_AUTO_LIST))(
+On an ambiguous completion, automatically list choices when the
+completion function is called twice in succession.  This takes
+precedence over tt(AUTO_LIST) and tt(LIST_AMBIGUOUS).  If
+tt(AUTO_MENU) is set, the menu behaviour will then start with the
+third press.
+)
 pindex(BEEP)
 cindex(beep, enabling)
 cindex(enabling the beep)
@@ -488,9 +497,10 @@
 cindex(ambiguous completion)
 cindex(completion, ambiguous)
 item(tt(LIST_AMBIGUOUS))(
-If this option is set, completions are shown only if the completions
-don't have a unambiguous prefix or suffix that could be inserted in
-the command line.
+This option works when tt(AUTO_LIST) is also set.  If there is an
+unambiguous prefix to insert on the command line, that is done without
+a completion list being displayed; in other words, auto-listing
+behaviour only takes place when nothing would be inserted.
 )
 pindex(LIST_BEEP)
 cindex(beep, ambiguous completion)
--- Src/Zle/zle_tricky.c.2tab	Thu Feb  4 11:02:49 1999
+++ Src/Zle/zle_tricky.c	Thu Feb  4 12:07:33 1999
@@ -270,6 +270,19 @@
        COMP_LIST_EXPAND };
 #define COMP_ISEXPAND(X) ((X) >= COMP_EXPAND)
 
+/* Non-zero if the last completion done was ambiguous (used to find   *
+ * out if AUTOMENU should start).  More precisely, it's nonzero after *
+ * successfully doing any completion, unless the completion was       *
+ * unambiguous and did not cause the display of a completion list.    *
+ * From the other point of view, it's nonzero iff AUTOMENU (if set)   *
+ * should kick in on another completion.                              *
+ *                                                                    *
+ * If both AUTOMENU and BASHAUTOLIST are set, then we get a listing   *
+ * on the second tab, a` la bash, and then automenu kicks in when     *
+ * lastambig == 2.                                                    */
+
+static int lastambig;
+
 /**/
 void
 completecall(void)
@@ -287,8 +300,13 @@
     useglob = isset(GLOBCOMPLETE);
     if (c == '\t' && usetab())
 	selfinsert();
-    else
-	docomplete(COMP_COMPLETE);
+    else {
+	if (lastambig == 1 && isset(BASHAUTOLIST) && !usemenu && !menucmp) {
+	    docomplete(COMP_LIST_COMPLETE);
+	    lastambig == 2;
+	} else
+	    docomplete(COMP_COMPLETE);
+    }
 }
 
 /**/
@@ -358,8 +376,13 @@
     useglob = isset(GLOBCOMPLETE);
     if (c == '\t' && usetab())
 	selfinsert();
-    else
-	docomplete(COMP_EXPAND_COMPLETE);
+    else {
+	if (lastambig == 1 && isset(BASHAUTOLIST) && !usemenu && !menucmp) {
+	    docomplete(COMP_LIST_COMPLETE);
+	    lastambig = 2;
+	} else
+	    docomplete(COMP_EXPAND_COMPLETE);
+    }
 }
 
 /**/
@@ -451,15 +474,6 @@
 
 static char *rdstr;
 
-/* Non-zero if the last completion done was ambiguous (used to find   *
- * out if AUTOMENU should start).  More precisely, it's nonzero after *
- * successfully doing any completion, unless the completion was       *
- * unambiguous and did not cause the display of a completion list.    *
- * From the other point of view, it's nonzero iff AUTOMENU (if set)   *
- * should kick in on another completion.                              */
-
-static int lastambig;
-
 /* This holds the name of the current command (used to find the right *
  * compctl).                                                          */
 
@@ -569,7 +583,8 @@
 
     /* Check if we have to start a menu-completion (via automenu). */
 
-    if ((amenu = (isset(AUTOMENU) && lastambig)))
+    if ((amenu = (isset(AUTOMENU) && lastambig &&
+		  (!isset(BASHAUTOLIST) || lastambig == 2))))
 	usemenu = 1;
 
     /* Expand history references before starting completion.  If anything *
@@ -5459,12 +5474,17 @@
 	if (isset(RECEXACT) && !lc && !ainfo->prerest)
 	    am = 1;
 
-	/* If the LIST_AMBIGUOUS option (meaning roughly `show a list only *
+	/*
+	 * If the LIST_AMBIGUOUS option (meaning roughly `show a list only *
 	 * if the completion is completely ambiguous') is set, and some    *
 	 * prefix was inserted, return now, bypassing the list-displaying  *
 	 * code.  On the way, invalidate the list and note that we don't   *
-	 * want to enter an AUTO_MENU imediately.                          */
-	if(isset(LISTAMBIGUOUS) && !am &&
+	 * want to enter an AUTO_MENU imediately.                          *
+	 *                                                                 *
+	 * We don't do this when BASH_AUTO_LIST is set, because that would *
+	 * mean you only got a completion list the third time you hit tab  *
+	 * (or whichever key).                                             */
+	if(isset(LISTAMBIGUOUS) && !isset(BASHAUTOLIST) && !am &&
 	   (ics != cs || (ainfo->suflen && !atend))) {
 	    invalidatelist();
 	    lastambig = 0;
@@ -5475,7 +5495,8 @@
      * if it is needed.                                                     */
     if (isset(LISTBEEP))
 	feep();
-    if (isset(AUTOLIST) && !amenu && !showinglist && smatches >= 2)
+    if (isset(AUTOLIST) && !isset(BASHAUTOLIST) && !amenu && !showinglist &&
+	smatches >= 2)
 	showinglist = -2;
     if (am)
 	lastambig = 1;
--- Src/options.c.2tab	Thu Feb  4 11:06:13 1999
+++ Src/options.c	Thu Feb  4 10:42:30 1999
@@ -90,6 +90,7 @@
 {NULL, "badpattern",	      OPT_EMULATE|OPT_NONBOURNE, BADPATTERN},
 {NULL, "banghist",	      OPT_EMULATE|OPT_NONBOURNE, BANGHIST},
 {NULL, "bareglobqual",        OPT_EMULATE|OPT_ZSH,       BAREGLOBQUAL},
+{NULL, "bashautolist",	      0,                         BASHAUTOLIST},
 {NULL, "beep",		      OPT_ALL,			 BEEP},
 {NULL, "bgnice",	      OPT_EMULATE|OPT_NONBOURNE, BGNICE},
 {NULL, "braceccl",	      0,			 BRACECCL},
--- Src/zsh.h.2tab	Thu Feb  4 11:07:22 1999
+++ Src/zsh.h	Thu Feb  4 10:44:55 1999
@@ -1057,6 +1057,7 @@
     BADPATTERN,
     BANGHIST,
     BAREGLOBQUAL,
+    BASHAUTOLIST,
     BEEP,
     BGNICE,
     BRACECCL,

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy