Re: Are completions in some way heavy?

[Sebastian Gniazdowski <sgniazdowski@xxxxxxxxx>]

On 7 June 2016 at 22:44, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> To your later point, *dis*abling a completion isn't something that I
> recall ever being closely considered.  The assumption was that if you
> didn't need a completion, it was either because you never used the
> corresponding command (maybe it isn't even available to you), or you
> always type out the arguments without pressing tab.

This is fine, all logical. However from practice about "having a clean
FPATH" I can maybe signal a topic about need of order of users.
Ability to do "disable debian", "disable cygwin", "enable osx", to
turn on and off needed/unneeded completions would bring this sense of
order maybe. But logically this is futile. Compdump optimizes greatly,
autoload keeps functions fit, user uses completions that he needs to
use, what's the point of disable/enable.

> I believe the problem is that some people expect completions to be more
> comprehensive/intuitive than they were ever intended to be.  Completion
> is supposed to save you keystrokes and occasionally to jog your memory;
> it's not supposed to be an AI that eliminates the need to think.
...
> } 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.
>
> Again if they are actually disturbing you, why are you invoking them
> in the first place?  They're not meant to slow you down.  If you have
> to patiently read, then seemingly you did need your memory jogged and
> the information is worthwhile?

Luckily an example can be provided. I was greeping for a text. It was
returning git objects. Wanted to disable lookup in binary files. But
can never remember is it "with-binary-files" or something similar
(turns out it's --binary-files, but my memory didn't play nice on
this). So I entered grep --with<TAB>. Nothing was returned. I might
have tried grep --binary and nothing would be returned because turns
out grep completion is very short on long options on OS X (no one
complained?). Reverted to manual. Entered "binary", found what was
needed, used it.

So why did I try completion. To take a guess maybe. This leads to an
idea of how this could be done:

- tab invokes "small man page" as it usually does after "command -<TAB>"
- the text can be searched – entering something greps lines in the "man page"
- bits of text can be navigated like in file completion when properly
configured – I mean cursor keys move the reverse highlight over what's
available

I have a proof of concept tool for this – h-list, horizontal list
(allows to browse elements horizontally). Might not look perfect as I
do (z) split on current line and don't restore spaces when displaying
(easy to fix):

https://asciinema.org/a/ewb3uj9095ixakd45yiztnqey
https://github.com/psprint/zsh-tools/

Also a bug revealed, searching for binary doesn't return
"--binary-files". Nevertheless, Zsh has apparently proper tools for
this task. Zcurses, desired performance (n-list, a vertical-only
version, processes 120k elements with no problem), approximate
matching.

> } Forward-portable?
>
> Meaning, a function deliberately written using syntax from an older
> version with the intention that it will run unchanged on all future
> versions.  That's fine for plugins that are meant to be compatible
> with many versions, but avoid replacing an improved version of
> something shipped with a newer zsh for no other reason than this.

Yes that's something not wanted. Maybe generations of the completions
could be done. Of course if anything will be actually done in the
topic as performance gain is a fail due to compdump optimizations.
Anyway, allocompletions-4, allcompletions-5.0.2, allcompletions-5.3.

Best regards,
Sebastian Gniazdowski