Bug w/matching control + feature request

[Felix Rosencrantz <f_rosencrantz@xxxxxxxxx>]

I'm seeing a problem with matching control and cursor placement.  I suspect
the problem might be related to too many match points...

Here's the case:

zsh@ zsh -f
host% echo $ZSH_VERSION
3.1.9-dev-8
host% autoload -U compinit ; compinit -D ; compdef _tst tst
host% _tst () {
function> compadd -M 'r:|[.,_-]=** r:[^0-9]||[0-9]=**' glibc-2.1.94-3.i386.rpm
glibc-devel-2.1.94-3.i386.rpm glibc-profile-2.1.94-3.i386.rpm
function> }
host% tst glibc-2.1<TAB>
results in: 
host% tst glibc-2[.]1.94-3.i386.rpm

With the cursor sitting on the dot after the 2, rather than before the 2,
which seems like the place it would end up.


Hmm...  Since the matching specs and cursor positioning came up again,
it got me thinking about a feature request I've wanted.   There are times
when matching places the cursor at the undesired spot for finishing the
completion of the word I'm completing.  The matching code has an idea of
where several other reasonable cursor positions are (see the code
at  zsh/Src/Zle/compresult.c:415, which picks from several possible
cursor locations as hot spots, there are probably a few more.) 

It seems like there would need to be a global array that is accessible to the
completion functions, that would hold valid hot spots in the current word.
It would then be possible to write a widget that would cycle the cursor
between these spots.

For the example above:
    glibc-2.1.94-3.i386.rpm
The valid spots would be just before the 2, and the end of the word, since
the word matches one of the choices.

-FR.

__________________________________________________
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.yahoo.com/