Re: Problem with completion matching control

Re: Problem with completion matching control

[Sven Wischnowsky]

I wrote:

> I'm tempted to remove the test that avoids calling the match-
> generation again, at least if the command line was changed. But then
> I'll have to make sure the interaction between listambiguous,
> automenu, autolist, bashautolist, and recexact still gives reasonable
> results, so this may take a while.

The patch below is a bit of an overhaul for the usage of completion
options in do_ambiguous(). A not-so-funny side effect is that the
match-generation code now gets called even if there is already a
list. This is needed to be able to detect when to use recexact
correctly, however.
User visible changes are that strings resulting from a `-M'-spec
behave the same as those from normal matching - this is in fact a bug
fix.
Another effect is that the automatically-use-automenu-if-recexact-is-set-
and-what-we-inserted-is-an-exact-match now magically appears after the 
list is shown, i.e. with possible matches `foo' and `foobar' and
listambiguous, automenu, and recexact set it completes `f' to `foo' of 
the first TAB, shows the list on the second TAB, and starts
menucompletion with the third TAB. This is the way automenu normally
behaves, so I hope you find it better than the `start menu-completion
and show the list now, ignoring listambiguous'-behavior we had before.
  

Bye
 Sven

diff -u os/Zle/zle_tricky.c Src/Zle/zle_tricky.c
--- os/Zle/zle_tricky.c	Mon Feb 15 12:51:57 1999
+++ Src/Zle/zle_tricky.c	Tue Feb 16 14:57:58 1999
@@ -287,6 +287,12 @@
 
 static int lastambig;
 
+/* Non-zero if the string on the line came from a previous completion. *
+ * This is used to detect if the string should be taken as an exact    *
+ * match (see do_ambiguous()).                                         */
+
+static int fromcomp;
+
 /**/
 void
 completecall(void)
@@ -2586,10 +2592,10 @@
 		    s = quotename(s, &e, te, &pl);
 		    sl = strlen(s);
 		}
-		if (!ms && ai->firstm) {
+		if (!ms) {
 		    if (sl < ai->minlen)
 			ai->minlen = sl;
-		    if ((i = sfxlen(ai->firstm->str, s)) < ai->suflen)
+		    if (ai->firstm && (i = sfxlen(ai->firstm->str, s)) < ai->suflen)
 			ai->suflen = i;
 		}
 		t = s;
@@ -2854,10 +2860,11 @@
     }
     if (!test)
 	return;
-    if (!ms && !ispattern && ai->firstm) {
+    if (!ms) {
 	if (sl < ai->minlen)
 	    ai->minlen = sl;
-	if ((test = sfxlen(ai->firstm->str, s)) < ai->suflen)
+	if (!ispattern && ai->firstm &&
+	    (test = sfxlen(ai->firstm->str, s)) < ai->suflen)
 	    ai->suflen = test;
     }
 
@@ -3464,14 +3471,13 @@
 
 static unsigned long ccont;
 
-/* Create the completion list.  This is called whenever some bit of  *
- * completion code needs the list.  If the list is already available *
- * (validlist!=0), this function doesn't do anything.  Along with    *
- * the list is maintained the prefixes/suffixes etc.  When any of    *
- * this becomes invalid -- e.g. if some text is changed on the       *
- * command line -- invalidatelist() should be called, to set         *
- * validlist to zero and free up the memory used.  This function     *
- * returns non-zero on error.                                        */
+/* Create the completion list.  This is called whenever some bit of   *
+ * completion code needs the list.                                    *
+ * Along with the list is maintained the prefixes/suffixes etc.  When *
+ * any of this becomes invalid -- e.g. if some text is changed on the *
+ * command line -- invalidatelist() should be called, to set          *
+ * validlist to zero and free up the memory used.  This function      *
+ * returns non-zero on error.                                         */
 
 /**/
 static int
@@ -3482,8 +3488,6 @@
 
     /* If we already have a list from a previous execution of this *
      * function, skip the list building code.                      */
-    if (validlist)
-	return !nmatches;
 
     if ((m = cmatcher)) {
 	Cmlist mm, *mp = &mm;
@@ -3515,7 +3519,8 @@
 
 	freecl = NULL;
 
-	lastambig = 0;
+	if (!validlist)
+	    lastambig = 0;
 	amatches = 0;
 	mnum = 0;
 	begcmgroup("default", 0);
@@ -5001,7 +5006,7 @@
 	listmatches();
     if(validlist)
 	freematches();
-    lastambig = menucmp = validlist = showinglist = 0;
+    lastambig = menucmp = validlist = showinglist = fromcomp = 0;
     menucur = NULL;
     compwidget = NULL;
 }
@@ -5437,14 +5442,13 @@
 do_ambiguous(void)
 {
     int p = (usemenu || ispattern), atend = (cs == we);
-    int am = 0;
 
     menucmp = 0;
 
     /* If we have to insert the first match, call do_single().  This is *
      * how REC_EXACT takes effect.  We effectively turn the ambiguous   *
      * completion into an unambiguous one.                              */
-    if (ainfo && ainfo->exact == 1 && isset(RECEXACT) &&
+    if (ainfo && ainfo->exact == 1 && isset(RECEXACT) && !fromcomp &&
 	(usemenu == 0 || unset(AUTOMENU))) {
 	do_single(ainfo->exactm);
 	invalidatelist();
@@ -5464,7 +5468,7 @@
 	 * normal menu completion options.                                 */
 	do_ambig_menu();
     } else {
-	int ics = cs, ocs, pl = 0, l, lp, ls;
+	int ics = cs, ocs, pl = 0, l, lp, ls, la = 0;
 	char *ps;
 	Cline lc;
 
@@ -5473,9 +5477,8 @@
 
 	fixsuffix();
 
-	/* Delete the old stuff from the command line. */
+	/* Prepare to delete the old stuff from the command line. */
 	cs = wb;
-	foredel(we - wb);
 
 	/* Sort-of general case: we have an ambiguous completion, and aren't *
 	 * starting menu completion or doing anything really weird.  We need *
@@ -5499,7 +5502,13 @@
 	    ls = ainfo->csl;
 	}
 	if (lc) {
-	    int sl = 0;
+	    VARARR(char, oline, ll);
+	    int sl = 0, oll = ll;
+
+	    memcpy(oline, line, ll);
+
+	    /* First remove the old string from the line. */
+	    foredel(we - wb);
 
 	    if (lp) {
 		if (ls) {
@@ -5514,7 +5523,21 @@
 		    merge_cline(lc, ps, lp, NULL, 0, 0);
 	    }
 	    inst_cline(lc, pl, sl);
+
+	    /* la is non-zero if listambiguous may be used. Copying and
+	     * comparing the line looks like BFI but it is the easiest
+	     * solution. Really. */
+	    la = (ll != oll || strncmp(oline, (char *) line, ll));
+
+	    /* If REC_EXACT and AUTO_MENU are set and what we inserted is an *
+	     * exact match, we want menu completion the next time round      *
+	     * so we set fromcomp,to ensure that the word on the line is not *
+	     * taken as an exact match.                                      */
+	    fromcomp = isset(AUTOMENU);
 	} else {
+	    /* First remove the old string from the line. */
+	    foredel(we - wb);
+
 	    inststrlen(ps, 1, -1);
 	    ocs = cs;
 	    if (brbeg && *brbeg) {
@@ -5535,24 +5558,21 @@
 		inststrlen(brend, 1, -1);
 	    }
 	    cs = ocs;
-	}
-	/* If REC_EXACT and AUTO_MENU are set and what we inserted is an   *
-	 * exact match, we want to start menu completion now. Otherwise    *
-	 * 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 && ps && ainfo->minlen == strlen(ps))
-	    am = 1;
+	    la = (ics != cs || (ainfo->suflen && !atend ));
 
+	    fromcomp = isset(AUTOMENU);
+	}
 	/*
 	 * 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 &&
-	   (ics != cs || (ainfo->suflen && !atend))) {
+	if(isset(LISTAMBIGUOUS) && la) {
+	    int fc = fromcomp;
+
 	    invalidatelist();
+	    fromcomp = fc;
 	    lastambig = 0;
 	    return;
 	}

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

Re: Problem with completion matching control

[Peter Stephenson]

Sven Wischnowsky wrote:
> The patch below is a bit of an overhaul for the usage of completion
> options in do_ambiguous().

There's now a widowed

    if (am)
	lastambig = 1;

at the end of do_ambiguous, with the declaration for `am' having
disappeared.  Can I just remove both lines?

-- 
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: Problem with completion matching control

[Sven Wischnowsky]

Bart Schaefer wrote:

> Sven Wischnowsky writes:
>  > 
>  > +/* This says what of the state the line is in when completion is started *
>  > + * came from a previous completion. If the FC_LINE bit is set, the       *
>  > + * string was inserted. If FC_INWORD is set, the last completion moved   *
>  > + * the cursor into the word although it was at the end of it when the    *
>  > + * last completion was invoked.                                          *
>  > + * This is used to detect if the string should be taken as an exact      *
>  > + * match (see do_ambiguous()) and if the cursor has to be moved to the   *
>  > + * end of the word before generating the completions.                    */
> 
> Is that really good enough?  Can't the cursor sometimes move from one
> place in the middle of a word, to some other place in the middle of
> the same word, depending on exactly what matches are generated?
> Particularly in the case (ahem) of a case-insensitive matcher?

As long as the line isn't changed by the user, the code places the
cursor always in the same place. If the line is changed, this flag is
reset anyway and the code places the cursor somewhere else anyway.
Yes, as far as I can think, this should solve the problem.

Bye
 Sven


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

Re: Problem with completion matching control

[Bart Schaefer]

Sven Wischnowsky writes:
 > 
 > +/* This says what of the state the line is in when completion is started *
 > + * came from a previous completion. If the FC_LINE bit is set, the       *
 > + * string was inserted. If FC_INWORD is set, the last completion moved   *
 > + * the cursor into the word although it was at the end of it when the    *
 > + * last completion was invoked.                                          *
 > + * This is used to detect if the string should be taken as an exact      *
 > + * match (see do_ambiguous()) and if the cursor has to be moved to the   *
 > + * end of the word before generating the completions.                    */

Is that really good enough?  Can't the cursor sometimes move from one
place in the middle of a word, to some other place in the middle of
the same word, depending on exactly what matches are generated?
Particularly in the case (ahem) of a case-insensitive matcher?

Re: Problem with completion matching control

[Sven Wischnowsky]

Oliver Kiddle wrote:

> There seems to be a few problems with the completeinword option though.
> Could someone offer a better explanation of what completeinword does
> than the documentation gives. I think that when I first configured zsh,
> I assumed that it allowed zsh to be more intelligent when completing
> with the cursor in the middle of the line so I set it.

With completeinword set the code splits the string on the line into a
prefix (before the cursor) and a suffix (after the cursor). Then it
generates the completions as usual, but it accepts only those strings
that have the prefix *and* the suffix from the line. I.e. with the
string `ab' and the cursor between the to only word beginning with `a' 
and ending with `b' are accepted.

> With autocd and completeinword set and the compctl MATCH 'm:{a-z}={A-Z}'
> from the zsh source directory, if I type 
> ./co<tab>
> I get completion working but it gets stuck on ./Config/. Is this a bug
> or what is intended by completeinword.

This was an ugly interaction between completeinword, listambiguous,
and automenu, actually. With listambiguous one more TAB is needed to
start menucompletion. But on the second TAB the cursor was moved into
the word, after the `c' to allow easy editing of the ambiguous
place. Without listambiguous menucompletion would now have been
started instead. But with listambiguous the next TAB made the code
search for a match beginning with `./c' and ending with `onfig' -- and 
there was only one such possible completion, the directory `Config'.
In a certain sense this was correct behavior. What made this
unacceptable was that there were no way to start automenu in such a
case. The patch below makes the code remember if it moved the cursor
into the word itself and restore the cursor to its old position before 
the next completion if that is the case.

> I also tested out your fix for the matching control which prevents *
> mapping to the anchor so ncftp sunsite.d<tab> works as I had wanted. I
> found the following which I think is a bug:
> 
> zsh -f
> setopt completeinword
> compctl -x 'p[1]' -k '(a.b.c a.c.b)' -M 'r:|.=*  r:|=*' -- t
> t a.<tab><tab><tab>
> 
> The above will complete to a.b.c, having never listed the alternatives.
> It works as I would expect when completeinword is not set.
> 
> I also get the following which is certainly worse:
> 
> First three commands same as above
> t a..c<left><left><tab>
> Gives me: zsh: 4013 segmentation fault
> With completeinword unsetopted, this works fine.

The first one is fixed by the patch below, too. The second one should
be fixed by the patch I sent yesterday.

Maybe noone understands me when I'm talking about the internals of the 
completion code, but still: these were caused by the current state of
the function join_clines(). The completion code builds lists of cline
structs to describe what should be put into the command line for each 
of the matches (actually, only for the complicated matches for which
match specs were used). After building such a list, join_clines() is
called to simplify the already existing cline list for the previous
matches so that it also adequately describes the new match. Most of
this function still comes from the days when we didn't have the new
completion code, the (big) patches from yesterday and last week
slightly improved it, but I still have to go through it once
more. This will then be my last change to the older completion code
apart from bug fixes for quite some time.
(You may now say that you didn't use the new completion stuff in the
example above -- you triggered a small error with setting flags in the 
cline struct that described the middle part of the string to insert,
the part where the prefix and the suffix meet).

Bye
 Sven

diff -u os/Zle/comp.h Src/Zle/comp.h
--- os/Zle/comp.h	Mon Feb 22 13:38:45 1999
+++ Src/Zle/comp.h	Tue Feb 23 09:02:31 1999
@@ -271,9 +271,10 @@
 #define CLF_MISS   4
 #define CLF_DIFF   8
 #define CLF_SUF   16
-#define CLF_NEW   32
-#define CLF_VAR   64
-#define CLF_JOIN 128
+#define CLF_PNEW  32
+#define CLF_SNEW  64
+#define CLF_VAR  128
+#define CLF_JOIN 256
 
 /* Flags for makecomplist*(). Things not to do. */
 
diff -u os/Zle/zle_tricky.c Src/Zle/zle_tricky.c
--- os/Zle/zle_tricky.c	Mon Feb 22 13:38:47 1999
+++ Src/Zle/zle_tricky.c	Tue Feb 23 10:39:28 1999
@@ -291,12 +291,24 @@
 
 static int lastambig;
 
-/* Non-zero if the string on the line came from a previous completion. *
- * This is used to detect if the string should be taken as an exact    *
- * match (see do_ambiguous()).                                         */
+/* This says what of the state the line is in when completion is started *
+ * came from a previous completion. If the FC_LINE bit is set, the       *
+ * string was inserted. If FC_INWORD is set, the last completion moved   *
+ * the cursor into the word although it was at the end of it when the    *
+ * last completion was invoked.                                          *
+ * This is used to detect if the string should be taken as an exact      *
+ * match (see do_ambiguous()) and if the cursor has to be moved to the   *
+ * end of the word before generating the completions.                    */
 
 static int fromcomp;
 
+/* This holds the end-position of the last string inserted into the line. */
+
+static int lastend;
+
+#define FC_LINE   1
+#define FC_INWORD 2
+
 /**/
 void
 completecall(void)
@@ -605,6 +617,12 @@
 	return;
     }
 
+    /* We may have to reset the cursor to its position after the   *
+     * string inserted by the last completion. */
+
+    if (fromcomp & FC_INWORD)
+	cs = lastend;
+
     /* Check if we have to start a menu-completion (via automenu). */
 
     if ((amenu = (isset(AUTOMENU) && lastambig &&
@@ -2346,7 +2364,7 @@
 	*olp = 0;
     if (nlp)
 	*nlp = 0;
-    if (o->flags & CLF_NEW) {
+    if (o->flags & CLF_PNEW) {
 	if (o->flags & (CLF_END | CLF_MID))
 	    /* We split the suffix in the middle and at the end into
 	     * separate runs. */
@@ -2363,7 +2381,7 @@
 		o->flags |= CLF_MISS;
 	}
     } else if (o->flags & (CLF_END | CLF_MID)) {
-	o->flags |= CLF_NEW;
+	o->flags |= CLF_PNEW;
 	o->prefix = join_ends(end_list(o->wlen, o->word),
 			      end_list(n->wlen, n->word), olp, nlp);
     } else if (o->wlen && n->wlen) {
@@ -2388,7 +2406,7 @@
 	     * matches both strings from the original cline structs
 	     * and thus can be put in the command line to represent
 	     * them. This cline list is stored in o. */
-	    o->flags |= CLF_NEW;
+	    o->flags |= CLF_PNEW;
 	    o->prefix = bld_new_pfx(o->wlen, o->word, n->wlen, n->word,
 				    &mol, &mnl, NULL);
 	    newl = 0;
@@ -2769,7 +2787,7 @@
 static void
 bld_sfx(Cline o, Cline n)
 {
-    if (o->flags & CLF_NEW) {
+    if (o->flags & CLF_SNEW) {
 	int miss;
 
 	o->suffix = join_new_sfx(o->suffix, n->wlen, n->word, &miss);
@@ -2785,7 +2803,7 @@
 	    new = dupstring(n->word);
 	    newl = n->wlen;
 	} else if (!strpfx(o->word, n->word)) {
-	    o->flags |= CLF_NEW;
+	    o->flags |= CLF_SNEW;
 	    o->suffix = bld_new_sfx(o->wlen, o->word, n->wlen, n->word,
 				    &mol, &mnl, NULL);
 	    newl = 0;
@@ -3234,6 +3252,7 @@
 	}
 	l = l->next;
     }
+    lastend = cs;
     /* Now place the cursor. Preferably in a position where something
      * is missing, otherwise in a place where the string differs from
      * any of the matches, or just leave it at the end. */
@@ -3873,6 +3892,7 @@
 	inststrlen(m->suf, 1, (l = strlen(m->suf)));
 	r += l;
     }
+    lastend = cs;
     cs = ocs;
     return r;
 }
@@ -6999,7 +7019,7 @@
     /* If we have to insert the first match, call do_single().  This is *
      * how REC_EXACT takes effect.  We effectively turn the ambiguous   *
      * completion into an unambiguous one.                              */
-    if (ainfo && ainfo->exact == 1 && isset(RECEXACT) && !fromcomp &&
+    if (ainfo && ainfo->exact == 1 && isset(RECEXACT) && !(fromcomp & FC_LINE) &&
 	(usemenu == 0 || unset(AUTOMENU))) {
 	do_single(ainfo->exactm);
 	invalidatelist();
@@ -7072,7 +7092,6 @@
 		    merge_cline(lc, ps, lp, NULL, 0, 0);
 	    }
 	    inst_cline(lc, pl, sl);
-
 	} else {
 	    inststrlen(ps, 1, -1);
 	    ocs = cs;
@@ -7093,6 +7112,7 @@
 		cs -= brsl;
 		inststrlen(brend, 1, -1);
 	    }
+	    lastend = cs;
 	    cs = ocs;
 	}
 	/* la is non-zero if listambiguous may be used. Copying and
@@ -7100,11 +7120,13 @@
 	 * solution. Really. */
 	la = (ll != oll || strncmp(oline, (char *) line, ll));
 
-	/* If REC_EXACT and AUTO_MENU are set and what we inserted is an *
-	 * exact match, we want menu completion the next time round      *
-	 * so we set fromcomp,to ensure that the word on the line is not *
-	 * taken as an exact match.                                      */
-	fromcomp = isset(AUTOMENU);
+	/* If REC_EXACT and AUTO_MENU are set and what we inserted is an  *
+	 * exact match, we want menu completion the next time round       *
+	 * so we set fromcomp,to ensure that the word on the line is not  *
+	 * taken as an exact match. Also we remember if we just moved the *
+	 * cursor into the word.                                          */
+	fromcomp = ((isset(AUTOMENU) ? FC_LINE : 0) |
+		    ((atend && cs != lastend) ? FC_INWORD : 0));
 
 	/*
 	 * If the LIST_AMBIGUOUS option (meaning roughly `show a list only *

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

Re: Problem with completion matching control

[Oliver Kiddle]

On Feb 18, 10:05am, Sven Wischnowsky wrote:

> Hm, still can't reproduce this. Do you still get the behavior (for the 
> other: completion after `t' and `te' behaved differently) with all
> recent patches: the completion option cleanup from 5399 with it's
> followup 5407 and the patch I sent yesterday in 5412?

I've just tested it with pws-9 and the problem has gone so one of those
patches must have fixed it. Thanks.

There seems to be a few problems with the completeinword option though.
Could someone offer a better explanation of what completeinword does
than the documentation gives. I think that when I first configured zsh,
I assumed that it allowed zsh to be more intelligent when completing
with the cursor in the middle of the line so I set it.

With autocd and completeinword set and the compctl MATCH 'm:{a-z}={A-Z}'
from the zsh source directory, if I type 
./co<tab>
I get completion working but it gets stuck on ./Config/. Is this a bug
or what is intended by completeinword.

I also tested out your fix for the matching control which prevents *
mapping to the anchor so ncftp sunsite.d<tab> works as I had wanted. I
found the following which I think is a bug:

zsh -f
setopt completeinword
compctl -x 'p[1]' -k '(a.b.c a.c.b)' -M 'r:|.=*  r:|=*' -- t
t a.<tab><tab><tab>

The above will complete to a.b.c, having never listed the alternatives.
It works as I would expect when completeinword is not set.

I also get the following which is certainly worse:

First three commands same as above
t a..c<left><left><tab>
Gives me: zsh: 4013 segmentation fault
With completeinword unsetopted, this works fine.

Anyway, I now have completeinword unsetopted in my setup so it isn't
bothering me.

Oliver Kiddle

Re: Problem with completion matching control

[Sven Wischnowsky]

Oliver Kiddle wrote:

> On Feb 16,  9:30am, Sven Wischnowsky wrote:
> 
> > I can't reproduce it, can you give me information about the completion 
> > options you have set or unset and any compctl's used here (global
> > matchers, default completion, special completion for the command,...).
> 
> It was from zsh -f so with all the default options and (lack of)
> completions. Only the one matching completion I mentioned. It also
> occurs with my setup; my options are:
> 
> setopt -09ghJOPRTX +16I setopt AUTO_PARAM_KEYS setopt AUTO_REMOVE_SLASH
> setopt COMPLETE_IN_WORD setopt EQUALS setopt EXTENDED_GLOB setopt
> EXTENDED_HISTORY setopt GLOB_COMPLETE setopt HIST_NO_STORE setopt
> LIST_AMBIGUOUS setopt LIST_BEEP setopt MULTIOS setopt POSIX_BUILTINS

Hm, still can't reproduce this. Do you still get the behavior (for the 
other: completion after `t' and `te' behaved differently) with all
recent patches: the completion option cleanup from 5399 with it's
followup 5407 and the patch I sent yesterday in 5412?

Bye
 Sven


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

Re: Problem with completion matching control

[Oliver Kiddle]

On Feb 16,  9:30am, Sven Wischnowsky wrote:

> I can't reproduce it, can you give me information about the completion 
> options you have set or unset and any compctl's used here (global
> matchers, default completion, special completion for the command,...).

It was from zsh -f so with all the default options and (lack of)
completions. Only the one matching completion I mentioned. It also
occurs with my setup; my options are:

setopt -09ghJOPRTX +16I setopt AUTO_PARAM_KEYS setopt AUTO_REMOVE_SLASH
setopt COMPLETE_IN_WORD setopt EQUALS setopt EXTENDED_GLOB setopt
EXTENDED_HISTORY setopt GLOB_COMPLETE setopt HIST_NO_STORE setopt
LIST_AMBIGUOUS setopt LIST_BEEP setopt MULTIOS setopt POSIX_BUILTINS

Incidentally, the -f option to zsh doesn't seem to be documented.

> No, the thing I found is this:
>   % setopt recexact; compctl -M 'm:{a-z}={A-Z}'
I get the same regardless of the state of recexact.

I've just noticed something else regarding matching control with my
ncftp compctl which uses 'r:|.=* r:|=*' the following happens:

ncftp sunsite.d<tab>

offers

sunsite.auc.dk and sunsite.doc.ic.ac.uk

This is exactly what I would expect from the matching but it isn't quite
what I want to achieve.

I've tried a number of things, mostly involving [^.]# in the tpat
without success. If anyone can work this out, I'd appreciate it - I've
given up for now because it's getting late.

Oliver Kiddle

Re: Problem with completion matching control

[Sven Wischnowsky]

Peter Stephenson wrote:

> Sven Wischnowsky wrote:
> > The patch below is a bit of an overhaul for the usage of completion
> > options in do_ambiguous().
> 
> There's now a widowed
> 
>     if (am)
> 	lastambig = 1;
> 
> at the end of do_ambiguous, with the declaration for `am' having
> disappeared.  Can I just remove both lines?

Yes (sorry, I had commented out the uses of am before and removed it
just before sending the patch, I thought I had re-compiled it, but
maybe without previously saving tricky.c).

Bye
 Sven

--- os/Zle/zle_tricky.c	Wed Feb 17 08:59:28 1999
+++ Src/Zle/zle_tricky.c	Wed Feb 17 08:59:33 1999
@@ -5584,8 +5584,6 @@
     if (isset(AUTOLIST) && !isset(BASHAUTOLIST) && !amenu && !showinglist &&
 	smatches >= 2)
 	showinglist = -2;
-    if (am)
-	lastambig = 1;
 }
 
 /* This is a stat that ignores backslashes in the filename.  The `ls' *

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

Re: Problem with completion matching control

[Sven Wischnowsky]

Oliver Kiddle wrote:

> Now this behaves in a way that I like:
> less t<tab><tab><tab>
> 
> But this behaves quite differently
> less te<tab><tab><tab>
> 
> ...
> 
> In the second case, the first tab completes to 'temp' and moves the
> cursor over the e as before but it doesn't list anything below. Any
> subsequent tabs do nothing.
> 
> In practical use, I tended to get the second scenario because I normally
> press tab after typing more than one character. Anyway, it is certainly
> the second case which I find annoying.

I can't reproduce it, can you give me information about the completion 
options you have set or unset and any compctl's used here (global
matchers, default completion, special completion for the command,...).

> > Playing with this I also noticed that there is some weird interaction
> > going on between inserting such a string and the setting of recexact
> > (the exact inserted match isn't immediatly accepted, which is wrong if 
> > auto_menu is unset). I'll have a lokk at this.
> 
> I'm not sure if its the same as what you've noticed there. I get some
> similar but different problems to what I described above when in the zsh
> source directory after:
> ./co<tab><tab>
> Here I again get no list and the menu completing stops at Config/ but
> this is only with my options - its fine with zsh -f.

No, the thing I found is this:

  % zsh -f
  % ls
  Temp    foo     foobar  temp
  % setopt recexact; compctl -M 'm:{a-z}={A-Z}'
  % ls f<TAB><TAB>
  
This completes and accepts `foo'.

  % ls t<TAB><TAB>
  Temp   temp

This completes to `temp' but does not accept it. In the meanwhile I
remembered that I knew about this when implementing the matching
stuff. The reason is that after the first TAB we can't easily find out 
that the string inserted is a possible match and once we have the list 
from the first TAB, the match-generation code isn't called again and
so the exact match isn't detected on the second TAB. And there is
more:

  % unsetopt listambiguous   # who made this be set by default?
  % ls f<TAB>
  foo     foobar

This shows the list and inserts `foo'. Further TABs will *not* accept
the match but start menucompletion. If automenu is unset, further TABs 
will do nothing.

I'm tempted to remove the test that avoids calling the match-
generation again, at least if the command line was changed. But then
I'll have to make sure the interaction between listambiguous,
automenu, autolist, bashautolist, and recexact still gives reasonable
results, so this may take a while.

Bye
 Sven


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

Re: Problem with completion matching control

[Oliver Kiddle]

On Feb 15, 10:42am, Sven Wischnowsky wrote:

> As for the cursor position: I tried to make the completion code clever 
> here by making it leave the cursor in the place where it is easiest to
> make the inserted line unambiguous. I know that this may look
> irritating but I think that this is the right thing to do. I could be
> convinced to make this controlled by an option, so that the cursor is
> left at the end if the option is unset.

I've done a few experiments and now agree with you that moving the
cursor back is better but I've also noticed something more subtle about
the behaviour which I think is a bug.

Starting with the usual:
zsh -f
compctl -M 'm:{a-z}={A-Z}'
:> temp > Temp

Now this behaves in a way that I like:
less t<tab><tab><tab>

But this behaves quite differently
less te<tab><tab><tab>

In the first case, the first tab completes 'temp', moves the cursor over
the e and lists 'Temp   temp' below the line. The second tab capitalises
the T and moves the cursor to the end. The third tab then lowercases the
t and any more tabs will continue to cycle.

In the second case, the first tab completes to 'temp' and moves the
cursor over the e as before but it doesn't list anything below. Any
subsequent tabs do nothing.

In practical use, I tended to get the second scenario because I normally
press tab after typing more than one character. Anyway, it is certainly
the second case which I find annoying.

> Playing with this I also noticed that there is some weird interaction
> going on between inserting such a string and the setting of recexact
> (the exact inserted match isn't immediatly accepted, which is wrong if 
> auto_menu is unset). I'll have a lokk at this.

I'm not sure if its the same as what you've noticed there. I get some
similar but different problems to what I described above when in the zsh
source directory after:
./co<tab><tab>
Here I again get no list and the menu completing stops at Config/ but
this is only with my options - its fine with zsh -f.

Thanks

Oliver Kiddle

Re: Problem with completion matching control

[Sven Wischnowsky]

Oliver Kiddle wrote:

> I've noticed the following behaviour which makes some sense but seems
> like a bug when first noticed.
> 
> zsh -f
> :> Temp
> :> temp
> compctl -M 'm:{a-z}={A-Z}'
> less t<tab>
> 
> Results in
> less temp
>       ^ - Cursor here. 'Temp' and 'temp' are listed below
> 
> So it if filling in the 'emp' which is unambiguous but moving the cursor
> back which I find very annoying. In my opinion, it should either
> complete to 'temp' or just beep and list the two files. The former would
> probably be better. Can the semantics of matching control be changed to
> accomodate this with out breaking it's other uses? i.e. Are there cases
> where the cursor moving back is useful?

As for the inserting and listing of matches: the explicitly used
matching spec makes both names possible matches, so only they should
be used and shown (after all that's what all this matching stuff is
about).
As for the cursor position: I tried to make the completion code clever 
here by making it leave the cursor in the place where it is easiest to
make the inserted line unambiguous. I know that this may look
irritating but I think that this is the right thing to do. I could be
convinced to make this controlled by an option, so that the cursor is
left at the end if the option is unset.

Playing with this I also noticed that there is some weird interaction
going on between inserting such a string and the setting of recexact
(the exact inserted match isn't immediatly accepted, which is wrong if 
auto_menu is unset). I'll have a lokk at this.

Bye
 Sven


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

Problem with completion matching control

[Oliver Kiddle]

I've noticed the following behaviour which makes some sense but seems
like a bug when first noticed.

zsh -f
:> Temp
:> temp
compctl -M 'm:{a-z}={A-Z}'
less t<tab>

Results in
less temp
      ^ - Cursor here. 'Temp' and 'temp' are listed below

So it if filling in the 'emp' which is unambiguous but moving the cursor
back which I find very annoying. In my opinion, it should either
complete to 'temp' or just beep and list the two files. The former would
probably be better. Can the semantics of matching control be changed to
accomodate this with out breaking it's other uses? i.e. Are there cases
where the cursor moving back is useful?

Thanks

Oliver Kiddle