_perl_modules broken?

_perl_modules broken?

[Adam Spiers]

As of the most recent CVS, every time I complete something which uses
_perl_modules to complete with, I get 

  _all_labels:34: command not found: -J

This could well be my faulty completion programming in _perl_modules,
but I'm afraid I haven't kept up-to-date with the many recent changes
so I have no idea how to fix it.

Also, _complete_help hasn't worked for me for a while now, e.g.

$ ls <TAB>
_complete_help:39: bad pattern: \n    all-files  (_files _default)

Re: _perl_modules broken?

[Bart Schaefer]

On Apr 11,  9:26pm, Adam Spiers wrote:
> Subject: _perl_modules broken?
> As of the most recent CVS, every time I complete something which uses
> _perl_modules to complete with, I get 
> 
>   _all_labels:34: command not found: -J

`perl -M<TAB>' works for me.  Have you a more specific example?

> This could well be my faulty completion programming in _perl_modules,
> but I'm afraid I haven't kept up-to-date with the many recent changes
> so I have no idea how to fix it.

Are you sure you're getting the most recent _perl_modules?  _wanted is
called at the end and now takes a command to execute as an argument, so
it looks to me as though you've got an updated _wanted but an older
_perl_modules.

> Also, _complete_help hasn't worked for me for a while now, e.g.
> 
> $ ls <TAB>
> _complete_help:39: bad pattern: \n    all-files  (_files _default)

I've no idea what would be happening there, but if _perl_modules is out
of date then so may other things be ...

_complete_help troubles

[Adam Spiers]

Bart Schaefer (schaefer@candle.brasslantern.com) wrote:
> Are you sure you're getting the most recent _perl_modules?  _wanted is
> called at the end and now takes a command to execute as an argument, so
> it looks to me as though you've got an updated _wanted but an older
> _perl_modules.

*sigh* Thanks, you're quite right.  My CVS working copy was perfectly
up to date, but I'd forgotten to remove some old _perl_modules from
elsewhere in my $fpath from when I was hacking on them.

> > Also, _complete_help hasn't worked for me for a while now, e.g.
> > 
> > $ ls <TAB>
> > _complete_help:39: bad pattern: \n    all-files  (_files _default)
> 
> I've no idea what would be happening there, but if _perl_modules is out
> of date then so may other things be ...

I'm pretty damn sure that everything's up to date now.  No .zwc files
around, no old functions elsewhere in $fpath ...

The relevant bit of trouble-making code is:

  for i in "${(@ok)help_funcs}"; do
    text="${text}
tags in context :completion:${i}:"
    tmp=()
    for j in "${(@s.:.)help_funcs[$i][2,-1]}"; do
      tmp=( "$tmp[@]" "${(@s.,.)help_tags[${i}${j}][2,-1]}" )
    done
    zformat -a tmp '  (' "$tmp[@]"
    tmp=( '
    '${^tmp}')' )             <<<<<< this line gives the error
    text="${text}${tmp}"
  done

tmp has the value `all-files  (_files _default' when the error occurs,
which doesn't look right.  Beyond that I'm lost, as I don't know what
_complete_help's output is supposed to be.  Sven?  Anybody?  Bueller?

Re: _complete_help troubles

[Bart Schaefer]

On Apr 11, 11:57pm, Adam Spiers wrote:
} Subject: _complete_help troubles
}
} > > $ ls <TAB>
} > > _complete_help:39: bad pattern: \n    all-files  (_files _default)

BTW, you do mean <C-x h> there, and not <TAB>, right?  If _complete_help
is running when you hit TAB, either you have rather surprising bindkeys,
or something very bad is happening.

} The relevant bit of trouble-making code is:
} 
}   for i in "${(@ok)help_funcs}"; do
}     text="${text}
} tags in context :completion:${i}:"
}     tmp=()
}     for j in "${(@s.:.)help_funcs[$i][2,-1]}"; do
}       tmp=( "$tmp[@]" "${(@s.,.)help_tags[${i}${j}][2,-1]}" )
}     done
}     zformat -a tmp '  (' "$tmp[@]"
}     tmp=( '
}     '${^tmp}')' )             <<<<<< this line gives the error
}     text="${text}${tmp}"
}   done
} 
} tmp has the value `all-files  (_files _default' when the error occurs,
} which doesn't look right.

No, that is in fact right.  The output should look something like

zagzig[99] ls <C-x h>
tags in context :completion::complete:ls::
    all-files  (_files _default)

and you'll note the ')' on the failing line.

However, look at this:

zagzig[99] setopt shwordsplit
zagzig[100] ls <C-x h>
tags in context :completion::complete:ls::
    all-files) 
    (_files) 
    _default)

I'm entirely certain that's NOT supposed to happen.  And then:

zagzig[109] setopt globsubst
zagzig[110] ls <C-x h>
_complete_help:39: bad pattern: \n    (_files)

So the problem is that _complete_help is expecting the standard options
from _main_complete, but of course it doesn't get them because it's not
called through the regular completion system.

Maybe we should put these (without localoptions, obviously) in another
function that can be called to install the standard completion options?

Except that rcexpandparam worries me just a tad ...

Index: Completion/Commands/_complete_help
===================================================================
@@ -1,6 +1,9 @@
 #compdef -k complete-word \C-xh
 
 _complete_help() {
+  setopt localoptions nullglob rcexpandparam extendedglob
+  unsetopt markdirs globsubst shwordsplit nounset ksharrays
+
   local _sort_tags=_help_sort_tags text i j k
   typeset -A help_funcs help_tags help_sfuncs help_styles
 

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

Re: _complete_help troubles

[Adam Spiers]

Bart Schaefer (schaefer@candle.brasslantern.com) wrote:
> On Apr 11, 11:57pm, Adam Spiers wrote:
> } Subject: _complete_help troubles
> }
> } > > $ ls <TAB>
> } > > _complete_help:39: bad pattern: \n    all-files  (_files _default)
> 
> BTW, you do mean <C-x h> there, and not <TAB>, right?  If _complete_help
> is running when you hit TAB, either you have rather surprising bindkeys,
> or something very bad is happening.

Oops, yes, I meant <C-x h> :-)

> So the problem is that _complete_help is expecting the standard options
> from _main_complete, but of course it doesn't get them because it's not
> called through the regular completion system.

Excellent, works now.  Thanks Bart.