Is this a bug or I'm completely lost?

Is this a bug or I'm completely lost?

[DervishD]

    Hi all :)

    If I run this script to setup a completion widget:

---
#!/bin/zsh

zle -C expand-or-complete expand-or-complete _completer

function _completer () {

    emulate -L zsh

    setopt extendedglob globdots globassign null_glob

    compstate[insert]=${compstate[insert]//tab /}

    compadd -k nameddirs userdirs

    return 0
}
---

    Then when I hit <TAB> I'm presented with the list of named
directories and user directories, in that order. That's correct. But
if I specify a starting letter (or any starting prefix) and I hit
<TAB>, only the first array is considered as a list of possible
matches. If I switch the order of the two arrays the behaviour is
reproducible: only the first one is used for matches.

    An example: if my named dirs are 'PWD' and 'OLDPWD' and my user dirs
are 'root' and 'user', with the script above I do:

    print r<TAB>

    and nothing is completed. If I switch the order of the array
names, it works, but then, with the order switched, I do:

    print P<TAB>

    and nothing is completed. If I change the compadd line in the
script above to:

    compadd -k nameddirs
    compadd -k userdirs

    then all works correctly, no matter the order.

    I'm using zsh-4.0.9, btw. I haven't found anything on the mailing
list archives nor in the changelogs (I have only the 4.1 changelogs).
Thanks!

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736
http://www.dervishd.net & http://www.pleyades.net/

Re: Is this a bug or I'm completely lost?

[Bart Schaefer]

On Thu, 4 Nov 2004, DervishD wrote:

>     compadd -k nameddirs userdirs
> 
>     Then when I hit <TAB> I'm presented with the list of named
> directories and user directories, in that order. That's correct. But
> if I specify a starting letter (or any starting prefix) and I hit
> <TAB>, only the first array is considered as a list of possible
> matches.

It certainly appears that this is the intentional behavior of compadd -k, 
based on a look at the code.  If you specify multiple arrays in a single 
compadd, they're assumed to indicate a preference ordering (e.g. nameddirs 
xor userdirs) whereas if you use separate compadds they're cumulative.  
The code very explicitly stops searching as soon as a partial match has 
been found; the only reason you get all of them in your first example is 
that there are no partial matches.

Unless of course I'm misreading the code, which is entirely possible given 
that Sven W. is really the only person who has ever had all of this inside 
his brain at one time.

I'm reluctant to try to change it given that there may be some obscure 
dependence on this ... just because I can't think of a case where the 
existing completion fuctions pass more than one array name to compadd, 
doesn't mean there isn't one.

On the other hand I don't want to change the docs if it really is a bug. 
Can someone else (Oliver?  PWS?) take a look at compcore.c:addmatches() 
and give a second opinion?  (Search with /arrays/i).

Re: Is this a bug or I'm completely lost?

[Peter Stephenson]

Bart Schaefer wrote:
> It certainly appears that this is the intentional behavior of compadd -k, 
> based on a look at the code.  If you specify multiple arrays in a single 
> compadd, they're assumed to indicate a preference ordering (e.g. nameddirs 
> xor userdirs) whereas if you use separate compadds they're cumulative.  
> The code very explicitly stops searching as soon as a partial match has 
> been found; the only reason you get all of them in your first example is 
> that there are no partial matches.

It's hard to believe it's a useful feature.  grep suggests it's not
used.  I can't see what you'd use it for.  Doesnt' ${array:-$array2}, or
something similar do it more clearly?

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: Is this a bug or I'm completely lost?

[DervishD]

    Hi Bart :)

 * Bart Schaefer <schaefer@brasslantern.com> dixit:
> >     compadd -k nameddirs userdirs
> >     Then when I hit <TAB> I'm presented with the list of named
> > directories and user directories, in that order. That's correct. But
> > if I specify a starting letter (or any starting prefix) and I hit
> > <TAB>, only the first array is considered as a list of possible
> > matches.
> It certainly appears that this is the intentional behavior of compadd -k, 
> based on a look at the code.  If you specify multiple arrays in a single 
> compadd, they're assumed to indicate a preference ordering (e.g. nameddirs 
> xor userdirs) whereas if you use separate compadds they're cumulative.  

    I assumed that, that's the reason I used a single compadd command
in the first place ;)

> The code very explicitly stops searching as soon as a partial match has 
> been found; the only reason you get all of them in your first example is 
> that there are no partial matches.

    The problem is that a partial match is not found. In fact, what
happens here is that if a match is not found in the first array, the
second is not even tried. Am I missing something?

> I'm reluctant to try to change it given that there may be some obscure 
> dependence on this ... just because I can't think of a case where the 
> existing completion fuctions pass more than one array name to compadd, 
> doesn't mean there isn't one.

    I'm with you... if this is a feature and not a bug.

    If, for example, you have 'cd r' in the command line and do
completion, and the first array has an entry called 'right' and the
second has one called 'rong', I find more or less intuitive and
useful that only 'right' is presented as a match, because you
specified and order when using one compadd command with two arrays.
The problem is that if the first array has no entry that matches that
'r', the second array is not even tried :(( For me this is a bug.

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736
http://www.dervishd.net & http://www.pleyades.net/

Re: Is this a bug or I'm completely lost?

[DervishD]

    Hi Peter :)

 * Peter Stephenson <pws@csr.com> dixit:
> > It certainly appears that this is the intentional behavior of compadd -k, 
> > based on a look at the code.  If you specify multiple arrays in a single 
> > compadd, they're assumed to indicate a preference ordering (e.g. nameddirs 
> > xor userdirs) whereas if you use separate compadds they're cumulative.  
> It's hard to believe it's a useful feature.  grep suggests it's not
> used.  I can't see what you'd use it for.  Doesnt' ${array:-$array2}, or
> something similar do it more clearly?

    Yes if the behaviour is 'xor', but I was looking for something
different: if no matches in the first array, try the second. That's
not 'if the first array is empty, try the second'.

    Currently you have 'if no matches in the first array, don't even
try the second' behaviour.

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736
http://www.dervishd.net & http://www.pleyades.net/

Re: Is this a bug or I'm completely lost?

[Bart Schaefer]

On Thu, 4 Nov 2004, DervishD wrote:

>     Currently you have 'if no matches in the first array, don't even
> try the second' behaviour.

In that case I've misread both the code and your original description of
the problem, and I'm much more convinced that it's a bug.

Try this.

--- compcore.c.~1.67.~	2004-06-07 07:55:38.000000000 -0700
+++ compcore.c	2004-11-04 20:17:16.000000000 -0800
@@ -2082,7 +2082,7 @@
 		    compignored++;
 		    if (dparr && !*++dparr)
 			dparr = NULL;
-		    continue;
+		    goto next_array;
 		}
 	    }
 	    if (!(dat->aflags & CAF_MATCH)) {
@@ -2100,7 +2100,7 @@
 					 &isexact))) {
 		if (dparr && !*++dparr)
 		    dparr = NULL;
-		continue;
+		goto next_array;
 	    }
 	    if (doadd) {
 		Brinfo bp;
@@ -2132,6 +2132,7 @@
 		}
 		free_cline(lc);
 	    }
+	next_array:
 	    if ((dat->aflags & CAF_ARRAYS) && !argv[1]) {
 		Heap oldheap2;
 

Re: Is this a bug or I'm completely lost?

[Bart Schaefer]

On Thu, 4 Nov 2004, Peter Stephenson wrote:

> > based on a look at the code.  If you specify multiple arrays in a 
> > single compadd, they're assumed to indicate a preference ordering 
> > (e.g. nameddirs xor userdirs) whereas if you use separate compadds 
> > they're cumulative.
> 
> It's hard to believe it's a useful feature.  grep suggests it's not 
> used.  I can't see what you'd use it for.  Doesnt' ${array:-$array2}, or 
> something similar do it more clearly?

Er, no, ${array:-$array2} would only work if $#array == 0.  You'd need 
something more baroque, such as

	compadd -A found -k array && compadd -a found
	(( $#found == 0 || $#found == $#array )) && compadd -k array2

The patch I sent does NOT implement the equivalent of the above.

Re: Is this a bug or I'm completely lost?

[DervishD]

    Hi Bart :)

 * Bart Schaefer <schaefer@brasslantern.com> dixit:
> >     Currently you have 'if no matches in the first array, don't even
> > try the second' behaviour.
> In that case I've misread both the code and your original description of
> the problem, and I'm much more convinced that it's a bug.
> 
> Try this.
[patch...]

    I'm trying it against a 4.2.1 (although I use 4.0.9), default
modules configuration, and it doesn't work :((

    If there isn't a WORD in the command line (apart for the command,
of course) and I hit TAB (bound to my special expand or complete),
I'm presented with the list of all named dirs (first) and user dirs
(last). That's correct because I specify 'compadd -k nameddirs
userdirs'. But if I use, for example 'cd r<TAB>', nothing is
completed, and userdirs has an entry for 'root' which should match :(

    If you want me to try anything more or if you want any info about
my environment or whatever, just tell.

    Thanks for your help and interest, Bart, you're great ;) As we
say in Spain, you're a 'tío de puta madre' ;)

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736
http://www.dervishd.net & http://www.pleyades.net/

Re: Is this a bug or I'm completely lost?

[DervishD]

    SORRY, SORRY, SORRY O:))

 * Bart Schaefer <schaefer@brasslantern.com> dixit:
> Try this.
[patch...]

    IT WORKS... I was testing with a script that had a bang path so
it was my old 4.0.9 who was failing. I sourced the script and now it
works O:)

    It works perfectly, all possible matches are presented if no
partial match is specified, sorted alphabetically (I mean, not
grouped by array of origin), and if I specify a partial match,
matches from *both* arrays are presented.

    Excuse me for the last message O:)

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736
http://www.dervishd.net & http://www.pleyades.net/

Re: Is this a bug or I'm completely lost?

[DervishD]

    Hi Bart :)

 * Bart Schaefer <schaefer@brasslantern.com> dixit:
> 	compadd -A found -k array && compadd -a found
> 	(( $#found == 0 || $#found == $#array )) && compadd -k array2
> The patch I sent does NOT implement the equivalent of the above.

    Maybe, but it works. At least it works as I consider 'the
intuitive way'. If I specify two or more arrays, what I want is the
whole list as a source of matches, mixed.

    Thanks again for the patch :) By now I'll use my old 4.0.9 and
two compadd commands, until 4.2.2 is out there.

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736
http://www.dervishd.net & http://www.pleyades.net/