Re: Bug w/matching control + feature request

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Felix Rosencrantz wrote:

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

Just to let everyone know: I'm working on this. The fix for the cursor 
positioning isn't all that difficult, but I know about two other test
cases with wrong behaviour and want to send a patch for all things
together. And since I'm still extremely busy...

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

I admit that I never thought of that. Sounds very sensible, and not
even too hard to implement. But I don't want to promise anything at
the moment...

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx