Re: BUG: Extended completion with alternative completion

Re: BUG: Extended completion with alternative completion

[Sven Wischnowsky]

Bart Schaefer wrote:

> ...
> 
> There are two problems: (1) in get_ccompctl(), when we chose to return
> the n[] completion, we lose track of the alternative (which hangs off
> the xor pointer in the head of the linked list of -x patterns); (2) we're
> prematurely returning an error in makecomplist(), so even if we still had
> the handle to the xor, we'd never follow it.
> 
> In short, alternative completion only works with extended completion when
> none of the extended patterns match, which doesn't seem right to me.
> 
> It's not hard to fix (2), but I'm leery of messing with (1) when there are
> a lot of other pending completion patches to be folded in to 3.1.6.  Sven,
> are you out there?
> 

Well, (1) is taken care of in the modifications of the completion code 
that are soon to appear.

And I have to admit that I don't really understand your other
problem. If you want cdmatch to be called even if the cursor is before 
the '/', you should use `C[0,*/*]', the manual says that with `n[i,s]' 
anything up to the i'th occurrence of s is not part of the completion
string, so the cursor isn't in a place where something can be
completed. Also I don't have any trouble with your second
compctl-version (trouble in the sense of SEGV or something like that).

So, could you please tell me what you wanted to have completed after
the `cd S/M'? (I guess you want `cd Src/Modules' but that would also
require a change in cdmatch.) Maybe I will then understand which fix
you are suggesting for (2).


Bye
 Sven


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

Re: BUG: Extended completion with alternative completion

[Bart Schaefer]

On Nov 2, 12:43pm, Sven Wischnowsky wrote:
} Subject: Re:  BUG: Extended completion with alternative completion
} 
} Bart Schaefer wrote:
} > There are two problems: (1) in get_ccompctl(), when we chose to return
} > the n[] completion, we lose track of the alternative (which hangs off
} > the xor pointer in the head of the linked list of -x patterns); (2) we're
} > prematurely returning an error in makecomplist(), so even if we still had
} > the handle to the xor, we'd never follow it.
} 
} Well, (1) is taken care of in the modifications of the completion code 
} that are soon to appear.

That's good.

} And I have to admit that I don't really understand your other
} problem. If you want cdmatch to be called even if the cursor is before 
} the '/', you should use `C[0,*/*]', the manual says that with `n[i,s]' 
} anything up to the i'th occurrence of s is not part of the completion

I don't actually want cdmatch to be called; I just used that as an example
because I can't get -anything- to be called.

What I want is for something else to be called when cdmatch doesn't give
any completions, e.g., cdmatch was called for n[-1,/] but result=().  The
definition of alternative completion is that the next alternative is tried
when the previous one doesn't produce any matches; that's all I'm trying to
get to have happen, and even the 3.0.5 manual claims that it should work
with the extended completion form that I used (`+' after the `--').

} Also I don't have any trouble with your second compctl-version
} (trouble in the sense of SEGV or something like that).

No, I don't either; just a feep() I that shouldn't be feeped.

} So, could you please tell me what you wanted to have completed after
} the `cd S/M'? (I guess you want `cd Src/Modules' but that would also
} require a change in cdmatch.) Maybe I will then understand which fix
} you are suggesting for (2).

I can show you directly what fix I'm suggesting for (2) (note, I do NOT
at this point recommend that anyone apply this patch, it has minimal
usefulness without also fixing what we're calling (1) here):

Index: zle_tricky.c
===================================================================
RCS file: /extra/cvsroot/zsh/zsh-3.1/Src/Zle/zle_tricky.c,v
retrieving revision 1.15
diff -u -r1.15 zle_tricky.c
--- zle_tricky.c	1998/10/30 17:52:48	1.15
+++ zle_tricky.c	1998/11/02 08:31:00
@@ -2290,7 +2290,7 @@
     s += *compadd;
     if ((offs -= *compadd) < 0)
 	/* It's bigger than our word prefix, so we can't help here... */
-	return 1;
+	goto xornext;
 
     /* Insert the prefix (compctl -P), if any. */
     if (cc->prefix) {
@@ -3037,6 +3037,8 @@
     validlist = 1;
     if (nmatches && !errflag)
 	return 0;
+
+  xornext:
 
     if ((isf || cc->xor) && !parampre) {
 	/* We found no matches, but there is a xor'ed completion: *

(In the `if ((isf ...' block is another goto that jumps back to the top
of makecomplist() to try again with cc->xor.)

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

BUG: Extended completion with alternative completion

[Bart Schaefer]

I'm fooling with the compctl for cdmatch from Misc/compctl-examples:

compctl -K cdmatch -S '/' -q -x 'p[2]' -Q -K cdmatch2 - \
	'S[/][~][./][../]' -g '*(-/)' + -g '*(-/D)' - \
	'n[-1,/]' -K cdmatch -S '/' -q -- cd chdir pushd

With this compctl installed (and no others except the 3.1.5 defaults, which
are essentially none), from the zsh-3.1.5 directory, the following setopts:

noautomenu            off
completealiases       off
completeinword        on		<-- This is important
globcomplete          off
menucomplete          off

I type:

zagzig<7> cd S/M

Now back up so the cursor is on the `S' and press TAB.  The n[-1,/] case is
chosen correctly by get_ccompctl() and returned to makecomplist().  At this
point we hit the following code:

    /* *compadd is the number of characters we have to ignore at the *
     * beginning of the word.                                        */
    wb += *compadd;
    s += *compadd;
    if ((offs -= *compadd) < 0)
	/* It's bigger than our word prefix, so we can't help here... */
	return 1;

offs <= *compadd, so 1 is returned to docompletion() at this code:

            /* Make sure we have the completion list and compctl. */
            if(makecomplist(s, incmd, &delit, &compadd, untokenized)) {
                /* Error condition: feeeeeeeeeeeeep(). */
                feep();
                goto compend;
            }

At this point we feep() and fail, mistakenly believing that an error has
occurred.  This appears harmless until the compctl is modified like so:

compctl -K cdmatch -S '/' -q -x 'p[2]' -Q -K cdmatch2 - \
	'S[/][~][./][../]' -g '*(-/)' + -g '*(-/D)' - \
	'n[-1,/]' -K cdmatch -S '/' -q -- + -K cdmatch -S '/' -q \
	cd chdir pushd                   ^^^^^^^^^^^^^^^^^^^^^^^

There are two problems: (1) in get_ccompctl(), when we chose to return
the n[] completion, we lose track of the alternative (which hangs off
the xor pointer in the head of the linked list of -x patterns); (2) we're
prematurely returning an error in makecomplist(), so even if we still had
the handle to the xor, we'd never follow it.

In short, alternative completion only works with extended completion when
none of the extended patterns match, which doesn't seem right to me.

It's not hard to fix (2), but I'm leery of messing with (1) when there are
a lot of other pending completion patches to be folded in to 3.1.6.  Sven,
are you out there?

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