Re: Are completions in some way heavy?

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Jun 6,  9:28pm, Sebastian Gniazdowski wrote:
}
} On 6 June 2016 at 18:01, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
} > Making it the user's responsibility to explicitly choose what to enable
} > is exactly what we wanted to *avoid*.

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.

Nevertheless:

} I in general don't like completions, must admit. They often interfere
} with what I want to do.

This statement is a bit baffling.  If this were really the case "in
general," why haven't you long ago re-bound TAB to something that
does not interfere, or simply stopped pressing it?

} 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..?).

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.  When
building compsys we made a pretty clear decision that completions would
only need to cover the majority of common cases and that offering too
many results which the user could narrow down was better than offering
too few.  Iterative refinement to perfection was never in scope, and in
fact is probably impossible because for every person who wants only UID
over 500 there's somebody else who only cares about the weird pseudo-
users he can't easily remember.

Which is why zstyle got added, so that you can do things like

    zstyle -e ':completion:*:su:*' users \
	'reply=( $(awk -F : "\$3 >= 500 { print \$1 }" < /etc/passwd) )'

} But it doesn't complete user names when invoked as "su - <TAB>".

Obviously some things are going to be in a grey area of whether they
are a "common case" and usually those things are worth fixing when
they turn up.  Still, it's telling that "su" completion has been around
for a long time and nobody bothered to complain about this before.

} 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?

} There are orders in magnitude of quality in such tasks like
} completion. [...]  Sometimes weird, like on Ubuntu where
} kill<TAB> invokes fzf.

Rather unfair to hold zsh compsys responsible for something built on
top of it by an OS distributor.

} 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.

It might be worth having a command (other than "unset _comps[thing]")
to easily remove an unwanted completion.

There is the under-utilized -first- context and corresponding _first
function which can be overridden to do things like suppress certain
completions.  The default _first is empty.

} 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.