Re: completion tricks

[Adam Spiers <adam@xxxxxxxxxx>]

Sven Wischnowsky (wischnow@xxxxxxxxxxxxxxxxxxxxxxx) wrote:
> > Would you mind showing how you do this quickly?
> 
> I use this:
> 
>     zrec() {
>       zrecompile "$@" -p -- \
>         -R ~/.zshrc -- \
>         -R ~/.zdump -- \
>         -R ~/lib/zsh/comp/Core/compinit -- \
>         -R ~/lib/zsh/comp/Core/compaudit -- \
>         -R ~/lib/zsh/comp/Core/compdump -- \
>         -M ~/lib/zsh/funcs.zwc \
>            ~/funcs/*(.) \
>            ~/lib/zsh/comp/*/_* \
>            ~/lib/zsh/func/*/*
>     }

That's very instructive; thanks.  Why .zdump not .zcompdump?

> Never mind the funny paths.

But I'm curious now :-)

Here's my version:

  #autoload

  _Core_dir=$fpath[(r)*Core*]
  _func_dir=${_Core_dir%/Completion/Core}

  zrecompile "$@" -p -- \
    -R ~/.zshenv -- \
    -R ~/.zshrc  -- \
    -R ~/.zcompdump  -- \
    -R $_Core_dir/compinit -- \
    -R $_Core_dir/compaudit -- \
    -R $_Core_dir/compdump -- \
    -M -U ~/.zsh/funcs.zwc \
          ~/.zsh/functions/*(*) \
          $_func_dir/Completion/*/_* \
          $_func_dir/Prompts/*

Seems to work fine.

> > zsh: parse error near `|'
> > zcompile: can't read file: /nfs-home/adams/local/share/zsh/4.0.1-pre-2/functions/Completion/Builtins/_vars_eq
> 
> There are only `||'s in _vars_eq, no `|'s.  Do you have any aliases
> that might get in the way?  You'll have to use `zcompile -U ...', then.

Ahah, well spotted.  I have a few single capital letter global aliases
which were getting in the way.

> > Also, for this to work, wouldn't I have to include ~/.zsh/comp.zwc in
> > fpath? 
> 
> Right.

OK.  Presumably it has to come before the normal Completion/* paths?
I find the ELEMENT.zwc bit of the manual pretty hard to understand.

When I put it at the head of fpath, memory consumption appears to
grow from:

USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
adams     1421  0.2  0.7  3092 2052 pts/12   S    16:48   0:00 ..../zsh

to:

USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
adams     1617  8.0  0.8  3772 2172 pts/3    S    16:50   0:00 ..../zsh

Why's that?  Startup time is better though, as expected.

> > Why did the example suggest only to compile Completion/*/_*,
> > not Completion/*/* ?
> 
> So that one saves the (probably not too large) space for the comp*
> functions which get called only seldom and unfunction themselves.  If
> they are in a mapped zwc file they might still be kept in memory even
> though they will never be called again through the lifetime of the shell.

Makes a lot of sense.

> > The more I think about it, the more I like the idea of `make install'
> > (or maybe `make install.zwc') taking the most sensible compilation
> > route.  The distribution's completion functions probably aren't going
> > to change at all in between upgrades, after all.
> 
> I wouldn't be against that, I just wouldn't know what style to suggest:
> one for all, one for each directory, and there are also the functions 
> in the Functions directory... Although users still have to call
> autoload with the function names they want so it isn't that big a
> problem if the global zwc digest contains functions some users don't
> want to use.  Hm.

Exactly.

> > Perhaps these performance hits should be mentioned in the manual?
> 
> Well, that putting many function into the completer style makes things 
> slower shouldn't be that surprising.  And for the match specs I'm not
> completely sure what to suggest (even thought I asked Peter to put
> something about that into the Guide, which he did).  Specs with `*'
> are slower than others, specs with `**' even more so.  But depending
> on the number, length and complexity of the matches one probably
> wouldn't notice that on modern computers.  Using many matchers with
> the matcher-list style can make things slow, too, but I always think
> that using to many different matchers isn't that good idea anyway
> (because they will probably match too often) so that users will find
> that out if they want or not anyway.
> 
> But of course I'm not against putting a little warning here and there
> into the manual.  Maybe we could first collect some reports from
> everyone here about things which they considered to be too slow (and
> how they solved it).

Sounds good.  So far, we have already mentioned _approximate and
_correct (I still haven't got round to figuring out the difference
between the two), and match specs.  Some completions used to be really
expensive, e.g. _perl_modules, _man, and _rpm, but hopefully the
caching helps a lot with that.  (Incidentally there are some rough
edges with the caching mechanism which I *still* haven't got round to
smoothing.)  Anything else?