Re: completion tricks

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Adam Spiers wrote:

> Matt Armstrong (matt.armstrong@xxxxxxxxxxxx) wrote:
> > I was using the new completion stuff for a while, but I switched back
> > for two reasons:
> > 
> >  - The learning curve to actually do stuff with the new completion
> >    stuff was above my personal threshold.
> > 
> >  - My shells started up many times slower with it in place.
> 
> This is a shame, but I can totally sympathise with your viewpoint.  I
> would love to hear some tips from any zsh-workers as to how zsh can be
> optimised with respect to startup time.

Normal users who have installed the functions in their home
directories or who can trust their system administrators can call
compinit with the -C option.  This avoids the security check
(compaudit) and it avoid parsing the tag lines of the completion files 
if there is already a dump file -- which means that people using -C
have to make sure the dump file is re-built when there are new or
changed completion functions (just removing the dump file is enough to 
trigger re-building it on the next invocation of compinit).

> (Optimisation w.r.t. memory
> usage is another topic I would like to hear people's thoughts on, but
> it's off-topic here.)  Personally I tried messing with zcompile and
> zrecompile once or twice to address this but ran out of time before I
> got it working, and anyway, Peter's guide suggests that on most
> computers these days it might not help much.  [Note to workers: would
> it be worth having `make install' automatically zcompile the
> completion system?]

On a stand-alone Linux box there probably really isn't that much
difference, but at least for me compiling the whole completion system
into a memory mapped digest file and using that makes things faster
(after the first function is loaded).  It also saves memory, of course 
because mapped files are shared by all instances of zsh running on the 
same host (if your OS supports that, but almost every Unix should).

> ...
> 
> > compctl is cryptic but pretty simple.  I hope it stays around.
> 
> I don't think there are any plans to get rid of it.

I once hoped we could get rid of it some years hence.  But since then
we've put it into a separate module, so I don't care about it anymore 
and it'll almost certainly survive.


Matt Armstrong wrote:

> ... [learning curve of the new completion system]
> 
> I was way beyond compinstall -- making custom completers for my own
> commands, etc.  Then I stepped back and analyzed the effort I was
> expending for the actual benefit.  Using compctl exclusively removes
> the temptation for spending time customizing every command I ever run.
> ;-)

I can easily understand reluctance to switch from compctl to the new
system once one has grokked the compctl man page ;-)

The difficulty is of course relative.  For very simple things compctls 
might be easier to write (if one doesn't have experience with the new
system), but as soon as we are talking about a completion for a
command with options and different arguments, the utility functions in 
the new system can make your live much easier (e.g. the _arguments
function).

> ...
> 
> Thinking back, startup time was not the problem that caused me to
> switch back.  It was the fact that simple tab file completion got
> slower.  Occasionally I'm doing stuff on slower systems with NFS file
> systems.  Completing files with TAB was noticeably slower with the new
> system over the old.

As Adam pointed out, this of course depends on the completers one uses 
(and the match specs, btw.).  It also heavily depends on the 3.1.x
version you tried.  Some time ago we added C-support for some of the
more heavily used completion functions, including, of course,
_path_files (which, not surprisingly, completes filenames and paths).
If you tried an earlier version I can understand your problems, but in 
a later version, and using a mapped function digest file completion is 
really pretty fast for me (we also had some other patches that made
the shell faster -- mainly due to the transition to the new internal
code representation (which also reduced the memory requirements)).


Anyway.  I can't and wouldn't want to force anyone to switch to the
new system -- but you miss a lot ;-)


Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx