Re: PATCH: Completion/matching control problem

Re: PATCH: Completion/matching control problem

[Sven Wischnowsky]

Peter Stephenson wrote:

> I've just stuck a
> message in Etc/BUGS.

Ah. Ugh. Sorry.

Bye
 Sven

--- Etc/BUGS.old	Mon Aug  2 14:49:33 1999
+++ Etc/BUGS	Mon Aug  2 14:49:44 1999
@@ -48,14 +48,3 @@
 <1-1000>33 will not match 633 because the 633 matches the range.  Some
 backtracking will be necessary.
 ------------------------------------------------------------------------
-Matching control can leave the wrong thing in the line.  For example,
-        touch Abc-Def-Ghij.txt
-        touch Abc-def.ghi.jkl_mno.pqr.txt
-        touch Abc_def_ghi_jkl_mno_pqr.txt
-        compctl -M 'm:{a-z}={A-Z} r:|[.,_-]=*'
-        ls a<TAB>
-produces
-        ls Abcdefghi
-which won't complete further.  It seems to get confused over the choice of
-possible punctuation characters, and the string won't complete further.
-------------------------------------------------------------------------

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

Re: PATCH: Completion/matching control problem

[Sven Wischnowsky]

Felix Rosencrantz wrote:

> Here's a problem with matching control that I encountered.  I've been
> meaning to send this patch in for some time.  If I understood the code
> better, I think I provide a cleaner test case.  
> 
> 	mkdir bug
> 	cd bug
> 	touch Abc-Def-Ghij.txt
> 	touch Abc-def.ghi.jkl_mno.pqr.txt
> 	touch Abc_def_ghi_jkl_mno_pqr.txt
> 	compctl -M 'm:{a-z}={A-Z} r:|[.,_-]=*'
> 	ls a-a<TAB>

There was also a problem in join_strs() which could cause an endless
loop. And if you have a matcher such as `m:-=[-_]', the string
inserted was sometimes not what you'd expect, e.g. after `ls Abc-d<TAB>'
where the `d' was removed. This was caused by the loop in
join_clines() which tried to find matching anchors even if the
prefixes before the current anchors matched. For now I have just
unc-commented that code -- I still like the idea.

Bye
 Sven

diff -u os/Zle/zle_tricky.c Src/Zle/zle_tricky.c
--- os/Zle/zle_tricky.c	Mon Aug  2 13:29:22 1999
+++ Src/Zle/zle_tricky.c	Mon Aug  2 14:31:20 1999
@@ -2871,7 +2871,8 @@
 			    *ap += mp->wlen; *alp -= mp->wlen;
 			    *bp += bl; *blp -= bl;
 			    t = 1;
-			}
+			} else
+			    t = 0;
 		    }
 		}
 	    }
@@ -3422,6 +3423,11 @@
 	    }
 	    /* Now see if they have matching anchors. If not, cut the list. */
 	    if (!(o->flags & CLF_MID) && !cmp_anchors(o, n, 1)) {
+#if 0
+		/* This used to search forward for matching anchors.
+		 * Unfortunately this does the wrong thing if the prefixes
+		 * before the differing anchors match nicely. */
+
 		Cline t, tn;
 
 		for (t = n; (tn = t->next) && !cmp_anchors(o, tn, 1); t = tn);
@@ -3430,6 +3436,7 @@
 		    n = tn;
 		    continue;
 		} else {
+#endif
 		    if (o->flags & CLF_SUF)
 			break;
 
@@ -3438,7 +3445,9 @@
 		    free_cline(o->next);
 		    o->next = NULL;
 		    o->flags |= CLF_MISS;
+#if 0
 		}
+#endif
 	    }
 	    /* Ok, they are equal, now join the sub-lists. */
 	    if (o->flags & CLF_MID)

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

Re: PATCH: Completion/matching control problem

[Sven Wischnowsky]

Felix Rosencrantz wrote:

> Here's a problem with matching control that I encountered.  I've been
> meaning to send this patch in for some time.  If I understood the code
> better, I think I provide a cleaner test case.  
> 
> 	mkdir bug
> 	cd bug
> 	touch Abc-Def-Ghij.txt
> 	touch Abc-def.ghi.jkl_mno.pqr.txt
> 	touch Abc_def_ghi_jkl_mno_pqr.txt
> 	compctl -M 'm:{a-z}={A-Z} r:|[.,_-]=*'
> 	ls a-a<TAB>
> 
> I sometimes see either a hang or a core dump.
> 
> The problem seems to occur when match_str is called with test=1 and abort_match
> is called, the globals matchparts&matchsubs end up pointing to free'd clines,
> which causes problems for code that attempts to append clines to the list.

It shouldn't call abort_match() at all when doing only testing (which
happens when it calls itself recursively while trying to match *-patterns).

> I another problem is if you type:
> 	ls a<TAB>
> you get:
> 	ls Abcdefghi
> which doesn't seem correct, but I figure someone who understands the code might
> be able to fix this one.

After trying word-strings and seeing that they didn't match it
compared line-strings even if they were empty (i.e. if it were in a
part of the matches that didn't have anything matching it on the
line). It should do that only at the end of the matches (which is
represented by a cline struct with an empty anchor).

That new place where CLF_MISS is set is needed to get the
cursor-placement right when the cline list was truncated.

Bye
 Sven

diff -u os/Zle/zle_tricky.c Src/Zle/zle_tricky.c
--- os/Zle/zle_tricky.c	Mon Aug  2 13:00:10 1999
+++ Src/Zle/zle_tricky.c	Mon Aug  2 13:21:55 1999
@@ -2542,9 +2542,12 @@
 	    lm = NULL;
 	} else {
 	    /* No matcher and different characters: l does not match w. */
+	    if (test)
+		return 0;
+
 	    abort_match();
 
-	    return (test ? 0 : -1);
+	    return -1;
 	}
     }
     /* If this is a recursive call, we just return if l matched w or not. */
@@ -2907,7 +2910,7 @@
     /* First try the exact strings. */
     if ((!(o->flags & CLF_LINE) && o->wlen == n->wlen &&
 	 (!o->word || !strncmp(o->word, n->word, o->wlen))) ||
-	(line = ((!o->line && !n->line) ||
+	(line = ((!o->line && !n->line && !o->wlen && !n->wlen) ||
 		 (o->llen == n->llen && o->line && n->line &&
 		  !strncmp(o->line, n->line, o->llen))))) {
 	if (line) {
@@ -3434,6 +3437,7 @@
 		    o->wlen = 0;
 		    free_cline(o->next);
 		    o->next = NULL;
+		    o->flags |= CLF_MISS;
 		}
 	    }
 	    /* Ok, they are equal, now join the sub-lists. */

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

Re: PATCH: Completion/matching control problem

[Peter Stephenson]

Felix Rosencrantz wrote:
> The problem seems to occur when match_str is called with test=1 and abort_mat
> ch
> is called, the globals matchparts&matchsubs end up pointing to free'd clines,
> which causes problems for code that attempts to append clines to the list.

This fix looks right.

> I another problem is if you type:
> 	ls a<TAB>
> you get:
> 	ls Abcdefghi
> which doesn't seem correct, but I figure someone who understands the code
> might be able to fix this one.

I suppose it's getting confused with the different possible punctuation
characters after Abc, but since it won't complete further, what it's doing
must be wrong --- it should presumably stop at that point or use menu
completion.  Unfortunately this won't get fixed until Sven reappears, and
since 3.1.6 is going to appear in the next few days, I've just stuck a
message in Etc/BUGS.

-- 
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

PATCH: Completion/matching control problem

[Felix Rosencrantz]

Here's a problem with matching control that I encountered.  I've been
meaning to send this patch in for some time.  If I understood the code
better, I think I provide a cleaner test case.  

	mkdir bug
	cd bug
	touch Abc-Def-Ghij.txt
	touch Abc-def.ghi.jkl_mno.pqr.txt
	touch Abc_def_ghi_jkl_mno_pqr.txt
	compctl -M 'm:{a-z}={A-Z} r:|[.,_-]=*'
	ls a-a<TAB>

I sometimes see either a hang or a core dump.

The problem seems to occur when match_str is called with test=1 and abort_match
is called, the globals matchparts&matchsubs end up pointing to free'd clines,
which causes problems for code that attempts to append clines to the list.

I another problem is if you type:
	ls a<TAB>
you get:
	ls Abcdefghi
which doesn't seem correct, but I figure someone who understands the code might
be able to fix this one.

--- os/Zle/zle_tricky.c		Sun Jul 25 18:38:50 1999
+++ Src/Zle/zle_tricky.c	Mon Jul 26 22:44:26 1999
@@ -2121,6 +2121,7 @@
 {
     free_cline(matchparts);
     free_cline(matchsubs);
+    matchparts = matchsubs = NULL;
 }
 
 /* This adds a new string in the static char buffer. The arguments are


_____________________________________________________________
Do You Yahoo!?
Free instant messaging and more at http://messenger.yahoo.com