Re: Are completions in some way heavy?

[Sebastian Gniazdowski <sgniazdowski@xxxxxxxxx>]

On 6 June 2016 at 18:01, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> On Jun 6,  2:43pm, Sebastian Gniazdowski wrote:
> }
> } This should provide speed up, to start with 15 enabled completions,
> } instead of 800 [...]
> }
> } That's a failure but I thought that maybe shell will be much lighter
> } with <100 completions pre-loaded? Maybe situation with compsys isn't
> } that bright because of the number of _* files? How can I reveal
> } effects of much lighter $functions, etc., is it possible?
>
> Functions that are marked for autoloading but haven't yet loaded are
> already very lightweight.  That was one reason for using a suite of
> files, so the autoload mechanism could take care of ignoring those
> that are never needed in a particular session.  Then compdump avoids
> the overhead of scanning directories to find those files.

The autoloading mechanism is indeed nice. The same for the compdump.
What's also nice is how easy it was to detach all completions from
Zsh. Simple copy of all "_*" files. And instant working when placed in
other directory that's in $fpath.

> Making it the user's responsibility to explicitly choose what to enable
> is exactly what we wanted to *avoid*.  If that's a requirement in order
> for the system to be "light enough" then we have failed.

I in general don't like completions, must admit. They often interfere
with what I want to do. Giving examples is much hard, such unpleasant
situations don't stick in memory. Maybe su. It completes fancy user
names on OS X . But ok, that's an acceptable must maybe (couldn't it
choose usernames with uid > 500 or something..?). But it doesn't
complete user names when invoked as "su - <TAB>". I guess patience is
needed for completions. They're like small man pages that disturb
view. One has to keep calm and try to read. Then it's fine.

There are orders in magnitude of quality in such tasks like
completion. This recalls me the various bootable CDs like Trinity,
Hiren's, Falcon, etc. How much effort can man put in making such
things better and better, more automated and robust? But only a few
people love doing such perfect things. The amount of work that I think
is needed for completions to cross next order of the magnitude would
require rapid iterations I guess, that's why I mentioned it. And I
wouldn't mind if I could disable and enable before that boundary is
crossed. But it's fine, completions are in general good. And there
undoubtedly is progress. Sometimes weird, like on Ubuntu where
kill<TAB> invokes fzf. Don't like the software because they did
history Ctrl-R via a hack: they don't parse multi-line entries,
instead they pass history event numbers together with one-line-packed
history entries, and then invoke vi-fetch-history:

https://github.com/junegunn/fzf/blob/master/shell/key-bindings.zsh#L42-L48

I ended up with 240 "crucial" completions when selecting what to keep
by default. But it was in 30% a hard decision process. 70% of what has
been rejected was easy. But uncertainty stays. Also, zplg cenable
takes completion's file name without _. This can of course not match
command name. Guess I could enable all multiple-argument compdefs by
default. grep "compdef [a-z]\+ [a-z]\+" * | wc -l says there are 172
such completions. What's the point currently? Having plugin manager
part-free. The 50-80ms is quite significant when compared to 250ms
when Zplugins loads 9 plugins with full shadowing, reporting,
including heavy plugins like z-sy-h and autosuggestions (70 ms in
"light" mode without reporting). But on other hand, what's really fun
is having completions detached from Zsh.

> } Also, overall, it would be nice that I would collect all mainstream _*
> } patches, and provide the completions for all Zsh versions.
>
> Having a location from which to grab .../share/$ZSH_VERSION/functions/
> trees for past zsh releases would be useful, particularly if fixes from
> more recent versions were backported when possible.
>
> I would not suggest attempting to create forward-portable versions of
> the functions.

Forward-portable?

Best regards,
Sebastian Gniazdowski