Re: Problem with completion matching control

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Oliver Kiddle wrote:

> Now this behaves in a way that I like:
> less t<tab><tab><tab>
> 
> But this behaves quite differently
> less te<tab><tab><tab>
> 
> ...
> 
> In the second case, the first tab completes to 'temp' and moves the
> cursor over the e as before but it doesn't list anything below. Any
> subsequent tabs do nothing.
> 
> In practical use, I tended to get the second scenario because I normally
> press tab after typing more than one character. Anyway, it is certainly
> the second case which I find annoying.

I can't reproduce it, can you give me information about the completion 
options you have set or unset and any compctl's used here (global
matchers, default completion, special completion for the command,...).

> > Playing with this I also noticed that there is some weird interaction
> > going on between inserting such a string and the setting of recexact
> > (the exact inserted match isn't immediatly accepted, which is wrong if 
> > auto_menu is unset). I'll have a lokk at this.
> 
> I'm not sure if its the same as what you've noticed there. I get some
> similar but different problems to what I described above when in the zsh
> source directory after:
> ./co<tab><tab>
> Here I again get no list and the menu completing stops at Config/ but
> this is only with my options - its fine with zsh -f.

No, the thing I found is this:

  % zsh -f
  % ls
  Temp    foo     foobar  temp
  % setopt recexact; compctl -M 'm:{a-z}={A-Z}'
  % ls f<TAB><TAB>
  
This completes and accepts `foo'.

  % ls t<TAB><TAB>
  Temp   temp

This completes to `temp' but does not accept it. In the meanwhile I
remembered that I knew about this when implementing the matching
stuff. The reason is that after the first TAB we can't easily find out 
that the string inserted is a possible match and once we have the list 
from the first TAB, the match-generation code isn't called again and
so the exact match isn't detected on the second TAB. And there is
more:

  % unsetopt listambiguous   # who made this be set by default?
  % ls f<TAB>
  foo     foobar

This shows the list and inserts `foo'. Further TABs will *not* accept
the match but start menucompletion. If automenu is unset, further TABs 
will do nothing.

I'm tempted to remove the test that avoids calling the match-
generation again, at least if the command line was changed. But then
I'll have to make sure the interaction between listambiguous,
automenu, autolist, bashautolist, and recexact still gives reasonable
results, so this may take a while.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx