Re: playing with backreferences in list-colors

Re: playing with backreferences in list-colors

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Jan 28,  6:14am, Bart Schaefer wrote:
> } Subject: Re: playing with backreferences in list-colors
> }
> } makes "path" be an unused parameter of clprintm.  Should it be removed
> } entirely, or is there a case in which it ought to be getting used?
> 
> To clarify:  The "path" parameter of iprintm, the only other function that
> is passed by pointer to printlist(), also is never used.

( ten out of ten points for seeing this... ;-) 

I was tempted to remove the argument, but: printlist() builds the path 
anyway and needs to do it to make the ztat(), so I thought I'd just
leave it in if anyone ever wants to write yet another lising module
which may want to have a look at it.

Bye
 Sven


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

Re: playing with backreferences in list-colors

[Bart Schaefer]

On Jan 28,  6:14am, Bart Schaefer wrote:
} Subject: Re: playing with backreferences in list-colors
}
} makes "path" be an unused parameter of clprintm.  Should it be removed
} entirely, or is there a case in which it ought to be getting used?

To clarify:  The "path" parameter of iprintm, the only other function that
is passed by pointer to printlist(), also is never used.

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

Re: playing with backreferences in list-colors

[Bart Schaefer]

On Jan 24, 10:54am, Sven Wischnowsky wrote:
} Subject: Re: playing with backreferences in list-colors
}
} Yes, it was indeed using the path, which was wrong in this case.

I know I'm running a few days behind here, but ...

This patch:

} -	    subcols = putfilecol(&mcolors, g->name, path, buf->st_mode);
} +	    subcols = putfilecol(&mcolors, g->name, m->str, buf->st_mode);

makes "path" be an unused parameter of clprintm.  Should it be removed
entirely, or is there a case in which it ought to be getting used?

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

Re: playing with backreferences in list-colors

[Alexandre Duret-Lutz]

After 9408 and 9416, I have still some problems :

1) listcolor stop colorization on the first (-1,-1) backref,
   even if there are valid backrefs after.

2) colorization of enclosed backrefs are wrongs.

   Let's say O denotes color for the outer block, I the inner color, 
   N means no color.  And I am matching over a 8 letter string.

   ((??)??)*   ->  OOOONNNN
   (?(??)?)*   ->  0IIIONNN   
   (??(??))*   ->  OOIIONNN

I expect the patch below to fix these two points. Sorting the 
end positions was needed to fix this second point (at least I 
didn't find any better way to do that).

The test `endpos[curisbeg] < begpos[curisbeg]' of the patch
is there to handle cases like :

~ % [[ fbar = (#b)f((o)#)bar ]]
~ % echo $mbegin / $mend
2 -1 / 1 -1

where the outer backref matched the empty string 
(empty strings don't need to be colored, I think).

Index: Src/Zle/complist.c
--- Src/Zle/complist.c Mon, 24 Jan 2000 13:43:41 +0100 Alexandre
+++ Src/Zle/complist.c Mon, 24 Jan 2000 15:25:07 +0100 Alexandre
@@ -391,7 +391,8 @@
 
 static int nrefs;
 static int begpos[MAX_POS], curisbeg;
-static int endpos[MAX_POS], curisend;
+static int endpos[MAX_POS];
+static int sendpos[MAX_POS], curissend; /* sorted end positions */
 static char **patcols, *curiscols[MAX_POS];
 static int curiscol;
 
@@ -450,29 +451,45 @@
 
     curiscols[curiscol = 0] = *patcols++;
 
-    curisbeg = curisend = 0;
+    curisbeg = curissend = 0;
 
-    for (i = nrefs;  i < MAX_POS; i++)
-	begpos[i] = endpos[i] = -1;
+    for (i = 0; i < nrefs; i++)
+	sendpos[i] = 0xfffffff;
+    for (; i < MAX_POS; i++)
+	begpos[i] = endpos[i] = sendpos[i] = 0xfffffff;
 }
 
 static void
 doiscol(Listcols c, int pos)
 {
-    if (endpos[curisend] >= 0 && pos > endpos[curisend]) {
-	curisend++;
+    int fi;
+
+    while (pos > sendpos[curissend]) {
+	curissend++;
 	if (curiscol) {
 	    zcputs(c, NULL, COL_NO);
 	    zlrputs(c, curiscols[--curiscol]);
 	}
     }
-    if (pos == begpos[curisbeg] && *patcols) {
-	curisbeg++;
-
-	zcputs(c, NULL, COL_NO);
-	zlrputs(c, *patcols);
-
-	curiscols[++curiscol] = *patcols++;
+    while (((fi = (endpos[curisbeg] < begpos[curisbeg] || 
+		  begpos[curisbeg] == -1)) ||
+	    pos == begpos[curisbeg]) && *patcols) {
+	if (!fi) {
+	    int i, j, e = endpos[curisbeg];
+	    
+	    /* insert e in sendpos */
+	    for (i = curissend; sendpos[i] <= e; ++i)
+		;
+	    for (j = i + 1; j < MAX_POS; ++j)
+		sendpos[j] = sendpos[j-1];
+	    sendpos[i] = e;
+	    
+	    zcputs(c, NULL, COL_NO);
+	    zlrputs(c, *patcols);
+	    curiscols[++curiscol] = *patcols;
+	}
+	++patcols;
+	++curisbeg;
     }
 }
 


-- 
Alexandre Duret-Lutz

Re: playing with backreferences in list-colors

[Sven Wischnowsky]

Alexandre Duret-Lutz wrote:

> ...
> 
> Does string="./aafoo" in frame #1 means that `(#b)(a)#*' is matched
> over "./aafoo" instead of only "aafoo"?

Yes, it was indeed using the path, which was wrong in this case.

The rest of the patch makes the complist module be loaded if the
list-colors style is used and it isn't already loaded and it makes the 
reported position of -1 be used correctly.

Bye
 Sven

diff -ru ../z.old/Completion/Core/_setup Completion/Core/_setup
--- ../z.old/Completion/Core/_setup	Mon Jan 24 09:58:02 2000
+++ Completion/Core/_setup	Mon Jan 24 10:35:30 2000
@@ -3,6 +3,7 @@
 local val nm="$compstate[nmatches]"
 
 if zstyle -a ":completion${curcontext}:$1" list-colors val; then
+  zmodload -e zsh/complist || zmodload -i zsh/complist
   if [[ "$1" = default ]]; then
     ZLS_COLORS="${(j.:.)${(@)val:gs/:/\\\:}}"
   else
diff -ru ../z.old/Src/Zle/complist.c Src/Zle/complist.c
--- ../z.old/Src/Zle/complist.c	Mon Jan 24 09:57:32 2000
+++ Src/Zle/complist.c	Mon Jan 24 10:44:16 2000
@@ -453,13 +453,13 @@
     curisbeg = curisend = 0;
 
     for (i = nrefs;  i < MAX_POS; i++)
-	begpos[i] = -1, endpos[i] = 0xfffffff;
+	begpos[i] = endpos[i] = -1;
 }
 
 static void
 doiscol(Listcols c, int pos)
 {
-    if (pos > endpos[curisend]) {
+    if (endpos[curisend] >= 0 && pos > endpos[curisend]) {
 	curisend++;
 	if (curiscol) {
 	    zcputs(c, NULL, COL_NO);
@@ -700,7 +700,7 @@
 	else if (mselect >= 0 && (m->flags & (CMF_MULT | CMF_FMULT)))
 	    zcputs(&mcolors, g->name, COL_DU);
 	else if (buf)
-	    subcols = putfilecol(&mcolors, g->name, path, buf->st_mode);
+	    subcols = putfilecol(&mcolors, g->name, m->str, buf->st_mode);
 	else
 	    subcols = putmatchcol(&mcolors, g->name, (m->disp ? m->disp : m->str));
 

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

Re: playing with backreferences in list-colors

[Sven Wischnowsky]

Peter Stephenson wrote:

> By the way:
> 
>        All three forms of name may be preceded by  a  pattern  in
>        parentheses. If such a pattern is given, the value will be
>        used only for matches in groups whose names are matched by
>        the  pattern  given  in the parentheses. E.g. `(g*)~m*=43'
>        says to highlight all matches beginning with `m' in groups
>        whose  names  begin with `g' using the color code `43'. In
>        case of the `lc', `rc', and `ec' codes, the group  pattern
>        is ignored.
> 
> What does the `~' in the example mean here?   Is that a misprint?

Yes.

Bye
 Sven

diff -ru ../z.old/Doc/Zsh/mod_complist.yo Doc/Zsh/mod_complist.yo
--- ../z.old/Doc/Zsh/mod_complist.yo	Mon Jan 24 09:57:40 2000
+++ Doc/Zsh/mod_complist.yo	Mon Jan 24 10:12:00 2000
@@ -100,7 +100,7 @@
 All three forms of var(name) may be preceded by a pattern in
 parentheses. If such a pattern is given, the var(value) will be used
 only for matches in groups whose names are matched by the pattern
-given in the parentheses. E.g. `tt((g*)~m*=43)' says to highlight all
+given in the parentheses. E.g. `tt((g*)m*=43)' says to highlight all
 matches beginning with `tt(m)' in groups whose names  begin with
 `tt(g)' using the color code `tt(43)'. In case of the `tt(lc)',
 `tt(rc)', and `tt(ec)' codes, the group pattern is ignored.

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

Re: playing with backreferences in list-colors

[Peter Stephenson]

Alexandre Duret-Lutz wrote:
> 
> I have been playing with list-colors to colorize 
> process listing and so on.  This is quite fun.
> The snipsets below show two problems I had
> 1) patterns containing letters don't seems to match;
> 2) backreferences when (x)# style patterns don't match make zsh segfault.

This is just an answer to half the story, namely the second part.  I hadn't
thought about backreferences which completely fail to match.  That happens
not just in this case, but also in for example:
  [[ abab = (#b)(([ab])#|([cd])#) ]]
where the second alternative, containing the third set of parentheses,
never matches, and you get the same segementation violation.

Luckily there's a variable around to check for whether they really
matched.  If they didn't, the matched string will now be set to the null
string, and both indices to -1.  -1 also gets passed back for the
complist code, although Sven can decide if he would prefer some other
behaviour since the chunk in pattryrefs() used in that case is different.

One thing is that without a great deal of rewriting it's not possible to
make (...)# do anything other than match one of the occurrences, so:

> (I know, `(a)#' is weird, but actualy I would like to be able
> to write something like `(*/)#([^ ]*)*' at the end of the pattern
> for my processes listings, to colorize only basename of processes)

... you should use (*/)([^ /]#)*, or something like that.  If you really
need to iterate parentheses, you could get away with using
`((*/)#)([^ ]*)*' and then making sure match 1 and match 2 are coloured the
same way (match 2 is a subset of match 1, but you need to specify some
behaviour for it anyway).  You can also sprinkle (#B)...(#b) pairs around,
to turn backreferences off temporarily, which is actually slightly more
efficient, but a bit ugly.

By the way:

       All three forms of name may be preceded by  a  pattern  in
       parentheses. If such a pattern is given, the value will be
       used only for matches in groups whose names are matched by
       the  pattern  given  in the parentheses. E.g. `(g*)~m*=43'
       says to highlight all matches beginning with `m' in groups
       whose  names  begin with `g' using the color code `43'. In
       case of the `lc', `rc', and `ec' codes, the group  pattern
       is ignored.

What does the `~' in the example mean here?   Is that a misprint?


Index: Src/pattern.c
===================================================================
RCS file: /home/pws/CVSROOT/projects/zsh/Src/pattern.c,v
retrieving revision 1.4
diff -u -r1.4 pattern.c
--- Src/pattern.c	1999/12/21 15:18:28	1.4
+++ Src/pattern.c	2000/01/22 19:45:17
@@ -1376,13 +1376,18 @@
 		ep = patendp;
 
 		for (i = 0; i < prog->patnpar && i < maxnpos; i++) {
-		    DPUTS(!*sp || !*ep, "BUG: backrefs not set.");
+		    if (parsfound & (1 << i)) {
+			if (begp)
+			    *begp++ = ztrsub(*sp, patinstart) + patoffset;
+			if (endp)
+			    *endp++ = ztrsub(*ep, patinstart) + patoffset - 1;
+		    } else {
+			if (begp)
+			    *begp++ = -1;
+			if (endp)
+			    *endp++ = -1;
+		    }
 
-		    if (begp)
-			*begp++ = ztrsub(*sp, patinstart) + patoffset;
-		    if (endp)
-			*endp++ = ztrsub(*ep, patinstart) + patoffset - 1;
-
 		    sp++;
 		    ep++;
 		}
@@ -1403,25 +1408,36 @@
 
 		PERMALLOC {
 		    for (i = 0; i < prog->patnpar; i++) {
-			DPUTS(!*sp || !*ep, "BUG: backrefs not set.");
-			matcharr[i] = dupstrpfx(*sp, *ep - *sp);
-			/*
-			 * mbegin and mend give indexes into the string
-			 * in the standard notation, i.e. respecting
-			 * KSHARRAYS, and with the end index giving
-			 * the last character, not one beyond.
-			 * For example, foo=foo; [[ $foo = (f)oo ]] gives
-			 * (without KSHARRAYS) indexes 1 and 1, which
-			 * corresponds to indexing as ${foo[1,1]}.
-			 */
-			sprintf(numbuf, "%ld",
-				(long)(ztrsub(*sp, patinstart) + patoffset +
-				       !isset(KSHARRAYS)));
-			mbeginarr[i] = ztrdup(numbuf);
-			sprintf(numbuf, "%ld",
-				(long)(ztrsub(*ep, patinstart) + patoffset +
-				       !isset(KSHARRAYS) - 1));
-			mendarr[i] = ztrdup(numbuf);
+			if (parsfound & (1 << i)) {
+			    matcharr[i] = dupstrpfx(*sp, *ep - *sp);
+			    /*
+			     * mbegin and mend give indexes into the string
+			     * in the standard notation, i.e. respecting
+			     * KSHARRAYS, and with the end index giving
+			     * the last character, not one beyond.
+			     * For example, foo=foo; [[ $foo = (f)oo ]] gives
+			     * (without KSHARRAYS) indexes 1 and 1, which
+			     * corresponds to indexing as ${foo[1,1]}.
+			     */
+			    sprintf(numbuf, "%ld",
+				    (long)(ztrsub(*sp, patinstart) + 
+					   patoffset +
+					   !isset(KSHARRAYS)));
+			    mbeginarr[i] = ztrdup(numbuf);
+			    sprintf(numbuf, "%ld",
+				    (long)(ztrsub(*ep, patinstart) + 
+					   patoffset +
+					   !isset(KSHARRAYS) - 1));
+			    mendarr[i] = ztrdup(numbuf);
+			} else {
+			    /* Pattern wasn't set: either it was in an
+			     * unmatched branch, or a hashed parenthesis
+			     * that didn't match at all.
+			     */
+			    matcharr[i] = ztrdup("");
+			    mbeginarr[i] = ztrdup("-1");
+			    mendarr[i] = ztrdup("-1");
+			}
 			sp++;
 			ep++;
 		    }
Index: Doc/Zsh/expn.yo
===================================================================
RCS file: /home/pws/CVSROOT/projects/zsh/Doc/Zsh/expn.yo,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 expn.yo
--- Doc/Zsh/expn.yo	1999/11/28 17:42:27	1.1.1.1
+++ Doc/Zsh/expn.yo	2000/01/22 19:30:06
@@ -1246,8 +1246,22 @@
 last match remains available.  In the case of global replacements this may
 still be useful.  See the example for the tt(m) flag below.
 
+The numbering of backreferences strictly follows the order of the opening
+parentheses from left to right in the pattern string, although sets of
+parentheses may be nested.  There are special rules for parentheses followed
+by `tt(#)' or `tt(##)'.  Only the last match of the parenthesis is
+remembered: for example, in `tt([[ abab = (#b)([ab])# ]])', only the final
+`tt(b)' is stored in tt(match[1]).  Thus extra parentheses may be necessary
+to match the complete segment: for example, use `tt(X((ab|cd)#)Y)' to match
+a whole string of either `tt(ab)' or `tt(cd)' between `tt(X)' and `tt(Y)',
+using the value of tt($match[1]) rather than tt($match[2]).
+
 If the match fails none of the parameters is altered, so in some cases it
-may be necessary to initialise them beforehand.
+may be necessary to initialise them beforehand.  If some of the
+backreferences fail to match --- which happens if they are in an alternate
+branch which fails to match, or if they are followed by tt(#) and matched
+zero times --- then the matched string is set to the empty string, and the
+start and end indices are set to -1.
 
 Pattern matching with backreferences is slightly slower than without.
 )

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>

playing with backreferences in list-colors

[Alexandre Duret-Lutz]

I have been playing with list-colors to colorize 
process listing and so on.  This is quite fun.
The snipsets below show two problems I had
1) patterns containing letters don't seems to match;
2) backreferences when (x)# style patterns don't match make zsh segfault.


% zsh -f
phobos% unset {,Z}LS_COLO{,U}RS          
phobos% autoload -U compinit; compinit; zmodload zsh/complist
phobos% zstyle ':completion:*' group-name ''
phobos% zstyle ':completion:*:files' list-colors '=(#b)(a)*=0=1'
phobos% setopt extendedglob 
phobos% touch a{a,b,c}foo
phobos% ls a<TAB>
aafoo   abfoo   acfoo                 # nothing is highlighted
phobos% zstyle ':completion:*:files' list-colors '=(#b)(?)*=0=1'
phobos% ls a<TAB>          
aafoo   abfoo   acfoo                 # first letters are highlighted
phobos% zstyle ':completion:*:files' list-colors '=(#b)a(*)=1=0'
phobos% ls a<TAB>
aafoo   abfoo   acfoo                 # nothing is highlighted

Can't I put letters in those patterns?

And now :

phobos% zstyle ':completion:*:files' list-colors '=(#b)(a)#*=1=0'  
phobos% ls a<TAB>
zsh: segmentation fault (core dumped)  zsh -f

(I know, `(a)#' is weird, but actualy I would like to be able
to write something like `(*/)#([^ ]*)*' at the end of the pattern
for my processes listings, to colorize only basename of processes)

(gdb) bt
#0  0x80a7a37 in ztrsub (t=0x40014c50 "", 
    s=0x40018001 <Address 0x40018001 out of bounds>)
    at ../../last/Src/utils.c:2594
#1  0x8094d5c in pattryrefs (prog=0x40014a98, string=0x40014c58 "./aafoo", 
    nump=0x401e2150, begp=0x401e2160, endp=0x401e21a0)
    at ../../last/Src/pattern.c:1382
#2  0x401de36e in putfilecol (c=0x401e2100, group=0x814d470 "files", 
    n=0x40014c58 "./aafoo", m=33204) at ../../../last/Src/Zle/complist.c:585
#3  0x401de92c in clprintm (g=0x814d670, mp=0x814d6e0, mc=0, ml=0, lastc=0, 
    width=8, path=0x40014c58 "./aafoo", buf=0xbffff308)
    at ../../../last/Src/Zle/complist.c:703

[...]

Does string="./aafoo" in frame #1 means that `(#b)(a)#*' is matched
over "./aafoo" instead of only "aafoo"?

BTW zsh seems to go into troubles when such a pattern don't match :

~ % zsh -f
phobos% setopt extendedglob
phobos% [[ ab = (#b)(a)#* ]] 
phobos% echo $match
a
phobos% [[ .ab = (#b)(a)#* ]] 
phobos% echo $match          
zsh: bad pattern: (
phobos% [[ ./ab = (#b)(a)#* ]] 
phobos% echo $match           
zsh: bad pattern: (
phobos% [[ ab = (#b)(a)#* ]] 
phobos% echo $match         
a
phobos% [[ aafoo = (#b)(a)#* ]] 
phobos% echo $match            
a
phobos% [[ .aafoo = (#b)(a)#* ]] 
phobos% echo $match             
O
phobos% [[ ./aafoo = (#b)(a)#* ]] 
phobos% echo $match              
O
phobos% [[ ./aaffffffffffffffffffffoo = (#b)(a)#* ]] 
phobos% echo $match                                 
f
phobos% [[ .ab = (#b)(a)#* ]] 
zsh: segmentation fault (core dumped)  zsh -f

(sometime it's faster to coredump)

(gdb) bt
#0  0x80a7a37 in ztrsub (t=0x40014fc1 "O\001@", 
    s=0x40018001 <Address 0x40018001 out of bounds>)
    at ../../last/Src/utils.c:2594
#1  0x8094ed7 in pattryrefs (prog=0x810b650, string=0x400153f8 ".ab", 
    nump=0x0, begp=0x0, endp=0x0) at ../../last/Src/pattern.c:1417
#2  0x80949f0 in pattry (prog=0x810b650, string=0x400153f8 ".ab")
    at ../../last/Src/pattern.c:1286
#3  0x805c025 in evalcond (state=0xbffff6c0) at ../../last/Src/cond.c:206
#4  0x8064407 in execcond (state=0xbffff6c0, do_exec=0)
    at ../../last/Src/exec.c:2856

[...]

-- 
Alexandre Duret-Lutz