Re: still confused about completion and matching

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Oct 12,  3:56pm, E. Jay Berkenbilt wrote:
} 
} What I want is effectively for the completion system to wait as long
} as possible before replacing a pattern with a match and to leave my
} cursor where it is when I hit TAB.

It took me at least as long to decide whether to answer this, and then
how much I had to add to what Sven said already, as Jay reported that
it took to compose his message in the first place; on top of that I've
been feverish all weekend, so I hope what I've finally ended up saying
makes at least a little bit of sense.

} If I type
} 
} zsh% ls u?/**/a_TAB
} 
} ideally, I like to see
} 
} zsh% ls u?/**/a_
} u2/q1/e2/a1  u2/q1/e2/a2  u4/q/a1  u4/q/a2
} 
} if I have extended_glob set (which is actually the thing that first
} made me switch to zsh).  Does this make sense?

One random aside:  You don't need extended_glob to use **.

It appears that _path_files isn't entirely prepared to deal with ** in
the input string.  The code after line 411 ("Step over to the next
component, if any") lops the ** out of the pattern, thus reducing the 
set of paths that are considered from ( u1/q1 u2/q1 u3/q1 u4/q ) to
just ( u4/q/a1 u4/q/a2 ).  So as things now stand:

	zsh -f
	% zstyle ':completion:*' completer _complete _match
	% autoload -U compinit; compinit -D
	% ls u?/**/a<C-D>
	u4/

Only `u4' is listed, even though `u1' and `u2' also contain matches of
the recursive pattern.  This means that even if you could get _path_files
to insert more than just the ambiguous prefix, you still won't see all
four of the possible completions you desire.

On Oct 13,  1:03pm, Sven Wischnowsky wrote:
> 
> [...] the path-prefixes and -suffixes [...]
> are still matched `normally'. And it has to be this way because the
> completion code (the C-code) has to be able to build a common string
> for them which it can if they differ only as far as match specs allow, 
> but it can't do that for arbitrary strings matched by a pattern.

It seems to me that _path_files (or perhaps even the C code) could employ
an algorithm similar to that cooked up by PWS for "zmv -w", to identify
glob patterns in the string from the command line and implicitly put them
in parens where necessary so that "match references" (there's another
overloading of "match") are generated, then used to identify "equivalent"
substrings in each of the potential matches.

> That leaves only the possibility to move the suffixes into the words
> given to compadd. This would be done in lines 488-510 in _path_files.
> That together with using a non-empty value for compstate[pattern_match]
> should bring you nearer to what you want. But note that this won't be
> added to _path_files if it is done unconditionally. Seeing only the
> ambiguous component is much clearer for most cases.

I mostly agree; however, with ** involved, there may be more than one
consecutive ambiguous path component.  This leads to confusing behavior
in which it's not clear without actually entering menu-completion exactly
where in the command line the listed completions would be inserted.  (The
`ambiguous' style notwithstanding.)

I had a bit more to ask about, but I came to the conclustion that I'm not
coherent enough yet to write it down, so I guess I'll leave it at that.

-- 
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