A couple completion glitches

A couple completion glitches

[Wayne Davison]

I've noticed that the new completion system won't ever complete a name
that matches the $fignore list, even if it is the only completion
possible.  The old completion system would go ahead and complete such
names if it was the only thing to do.  For example, if I have ".old"
in $fignore and the files "foo" and "foo.old" exist, both systems
handle "f<tab>" the same -- it expands to "foo ".  I used to be able
to append a '.', press <tab>, and get "foo.old", now I can't.  Is
this intentional?

Secondly, there seems to be an inconsistency in the handling of glob
characters.  For instance:

    % autoload -U compinit
    % compinit -D
    % zstyle ':completion:*' completer _expand _complete
    % bindkey '^i' complete-word
    % cd ~
    % touch foo{1..3}
    % ls ~/foo*<tab>

...and nothing happens!  Removing the "~/" works around the problem:

    % ls foo*<tab>

This results in the following menu expansion:

    % ls foo*
    foo*             foo1 foo2 foo3
    foo1       foo2       foo3

Strangely, setting "zstyle ':completion:*' original false" doesn't
remove the "foo*" from the list -- should it?

One more inconsistency results from the same setup, and this expansion:

    % ls foo?<tab>

This results in a slightly differ ordering (due to ASCII sorting):

    % ls foo1 foo2 foo3
    foo1 foo2 foo3   foo?
    foo1       foo2       foo3

In my mind, I would like it to always order the full expansion and the
original string into the same places, regardless of ASCII order (to
make it more consistent).  Perhaps always put the multi-item expansion
first and the original string last?

..wayne..

Re: A couple completion glitches

[Bart Schaefer]

On Jun 24, 12:54pm, Wayne Davison wrote:
} Subject: A couple completion glitches
}
} I've noticed that the new completion system won't ever complete a name
} that matches the $fignore list, even if it is the only completion
} possible.

Yes, that's correct.  To get the new completion system to act like the
old one, you need something like

    zstyle ':completion:*:all-files' ignored-patterns \*$^fignore

} Secondly, there seems to be an inconsistency in the handling of glob
} characters.  For instance:
} 
}     % autoload -U compinit
}     % compinit -D
}     % zstyle ':completion:*' completer _expand _complete
}     % bindkey '^i' complete-word
}     % cd ~
}     % touch foo{1..3}
}     % ls ~/foo*<tab>
} 
} ...and nothing happens!

I was about to say that you need to set the suffix style, but that does
not work either.

Hmm; looks like there's a bug in `zstyle -T', though I have no idea how
that crept in.  Look here:

zagzig% zstyle -L
zstyle ':completion:*' completer _expand _complete
zstyle ':completion:*:expand:*' suffix yes
zagzig% zstyle -t :completion::expand::: suffix && echo suffix is set  
suffix is set
zagzig% zstyle -T :completion::expand::: suffix && echo suffix not set
suffix not set

It shouldn't be possible for them both to return true.

} One more inconsistency results from the same setup, and this expansion:
} 
}     % ls foo?<tab>
} 
} In my mind, I would like it to always order the full expansion and the
} original string into the same places, regardless of ASCII order (to
} make it more consistent).  Perhaps always put the multi-item expansion
} first and the original string last?

This could be accomplished by having _expand put the original string in
its own compadd group.  That means a bit of restructuring of _expand to
store the original string separately until it is known whether there are
any other expansions possible.

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: A couple completion glitches

[Bart Schaefer]

On Jun 24, 11:00pm, I wrote:
}
} Hmm; looks like there's a bug in `zstyle -T', though I have no idea how
} that crept in.  Look here:
} 
} zagzig% zstyle -L
} zstyle ':completion:*' completer _expand _complete
} zstyle ':completion:*:expand:*' suffix yes
} zagzig% zstyle -t :completion::expand::: suffix && echo suffix is set  
} suffix is set
} zagzig% zstyle -T :completion::expand::: suffix && echo suffix not set
} suffix not set
} 
} It shouldn't be possible for them both to return true.

Of course, I'm silly.  It certainly should be possible for both to return
true.  I keep forgetting that the difference between -t and -T is how they
treat the case of the style NOT being set, not how they treat it when it
IS set.

So in fact for the original question:

} }     % touch foo{1..3}
} }     % ls ~/foo*<tab>
} } 
} } ...and nothing happens!

You DO need to set the suffix style, but you need to set it to "false".

Which, now that I think about it, sounds backwards to me.  It means "do
not make a special case of expansions that have a suffix" but it *seems*
to mean "do not expand the suffix."  Which is how I got confused about
what _expand was testing with "zstyle -T" in the first place ...

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: A couple completion glitches

[Wayne Davison]

On Sat, 24 Jun 2000, Bart Schaefer wrote:
> You DO need to set the suffix style, but you need to set it to "false".

This has an unfortuante side-effect.  It does fix the problem I
complained about, though:

    % touch ~/foo{1..3}
    % zstyle ':completion:*:expand:*' suffix false
    % ls ~/foo*<tab>

This becomes the proper:

    % ls ~/foo1 ~/foo2 ~/foo3
    ~/foo1 ~/foo2 ~/foo3
    ~/foo1   ~/foo2   ~/foo3
    ~/foo*

However, the following behaves in a very undesireable manner:

    % ls ~/foo<tab>

This becomes:

    % ls /home/wayne/foo
    /home/wayne/foo
    ~/foo

Which is not what I want at all.

It still seems strange to me that (without the above suffix option)
foo* gets glob expansion but ~/foo* does not.  Surely this should not
be the default even if this turns out (for some strange reason) not to
be a bug.

BTW, thanks for pointing out the "group-name" setting.  I think that
might be what I will choose to use (and it is reflected in the above
menu-completion output).

..wayne..

Re: A couple completion glitches

[Bart Schaefer]

On Jun 25,  1:38am, Wayne Davison wrote:
} Subject: Re: A couple completion glitches
}
} On Sat, 24 Jun 2000, Bart Schaefer wrote:
} > You DO need to set the suffix style, but you need to set it to "false".
} 
} This has an unfortuante side-effect.
} 
}     % ls ~/foo<tab>
} 
} This becomes:
} 
}     % ls /home/wayne/foo
}     /home/wayne/foo
}     ~/foo
} 
} Which is not what I want at all.

That's because the keep-prefix style defaults to "changed" which means
that the prefix expands if and only if the suffix does not.  So you also
want

    zstyle ':completion:*:expand:*' keep-prefix true

which means to never expand the prefix.

} It still seems strange to me that (without the above suffix option)
} foo* gets glob expansion but ~/foo* does not.  Surely this should not
} be the default even if this turns out (for some strange reason) not to
} be a bug.

I never noticed this myself because using

    zstyle ':completion:*' matcher-list '' 'r:|[._-,]=* r:|=*'
    zstyle ':completion:*' completer _expand _complete _match

causes most glob expansions to occur during the matching phase.

In light of the examples you've given, I think the suffix style should
have its meaning completely reversed (which probably means we ought to
change its name, sigh) so that the default is to expand the suffix and
the setting "false" means to NOT expand it.

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: A couple completion glitches

[Bart Schaefer]

On Jun 24, 11:00pm, I wrote:
}
} } In my mind, I would like it to always order the full expansion and the
} } original string into the same places, regardless of ASCII order (to
} } make it more consistent).  Perhaps always put the multi-item expansion
} } first and the original string last?
} 
} This could be accomplished by having _expand put the original string in
} its own compadd group.  That means a bit of restructuring of _expand to
} store the original string separately until it is known whether there are
} any other expansions possible.

On further investigation, I find I'm wrong about this, too; I misread the
last part of _expand where the compadd commands are performed.

The original completion already IS being added in a separate completion
group; the only thing you need to do to have it always listed last is

    zstyle ':completion:*' group-name ''

If you don't like that behavior for regular completion, limit it:

    zstyle ':completion:*:expand:*' group-name ''

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net