Re: Questions regarding _hosts completion extension

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Mon, Jun 27, 2022 at 2:37 PM Mikhail f. Shiryaev
<mr.felixoid@xxxxxxxxx> wrote:
>
> It doesn't use cache features, so the shell instances don't share the state between them
> It fills up the _cache_hosts only once at the first completion, and the only way to refresh it is `unset _cache_hosts`. A bit obscured

Related https://zsh.org/workers/49676 which was put off for "code
freeze" even though clearly code didn't actually freeze then.

> If one wants to extend the function with his values, then a way to go suggested on the Internet is defining a style `zstyle -e ':completion:*:hosts' hosts 'reply=(...)`. Unfortunately, it completely overrides the original function.

You can always write a new function e.g. _my_hosts that calls _hosts
as a fallback, and then just do (after compinit) compdef _hosts ssh
...

Alternately,
  functions -c _hosts _original_hosts
  _hosts() {
    # do your own thing, else
    _original_hosts
  }

> If `reply` executes any function or binary under the hood, the terminal hangs after each <tab> pressing.
[...]
> I'd like to ask about your opinion [...] For example, if async shouldn't be used in completion.

Elaborating on what Eric said ... without some pretty fancy plumbing,
a background job can't return results into the completion.  Glancing
at your code, it looks like you're filling the cache files in the
background, which means your TAB-press results will include a
gradually increasing subset of possible matches (possibly none, the
first time) until the cache finishes filling.  I guess that's OK if
it's more important to you to be able to keep typing than to have
accurate results, but you may have an uphill battle to get something
like that into the upstream.  I haven't tried to work out what happens
if you start a completion in a second shell before the background
cache-fill has finished in the first shell.