Questions regarding _hosts completion extension

Questions regarding _hosts completion extension

[Mikhail f. Shiryaev]

[-- Attachment #1: Type: text/plain, Size: 1918 bytes --]

Hello dear workers,
I have some questions regarding a stock _hosts completion function.

The original function, IMHO, has a few flaws that kind of difficult to
address without a heavy development, in particular:

   - 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
   - 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.
   - If `reply` executes any function or binary under the hood, the
   terminal hangs after each <tab> pressing.

I've spent some time developing a solution addressing all mentioned points.
It's the third implementation. The first one was done as an internal
product, and the two last are in my repository
https://github.com/Felixoid/zsh-hoco/blob/master/hoco.zsh. Features it has:

   - Users can set HOCO_FUNCTIONS array. Then its output will be split by
   spaces, tabs, and new lines, and used as the hosts' completion.
   - Uses the cache functions _store_cache, _retrieve_cache, and
   _cache_invalid. The cache content is shared between instances when
   `:completion:* use-cache` is set.
   - Functions or binaries are executed in the background and don't block
   the terminal.


I'd like to ask about your opinion if it makes sense to bring it to the
upstream. I am sure it still doesn't comply with the requirements for 100%
and can be improved. On the other hand, it brings many advantages. I'd like
to hear your opinion before trying to prepare a patch if it completely
breaks some rules though. For example, if async shouldn't be used in
completion.

What do you think?

Best regards,
Mikhail f. Shiryaev

[-- Attachment #2: Type: text/html, Size: 2364 bytes --]

Re: Questions regarding _hosts completion extension

[Eric Cook]

On 6/27/22 17:37, Mikhail f. Shiryaev wrote:
> Hello dear workers,
> I have some questions regarding a stock _hosts completion function.
>
> The original function, IMHO, has a few flaws that kind of difficult to address without a heavy development, in particular:
>
>   * 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
Would be a useful improvement

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

zstyle ':completion:*:hosts' fake foo bar # or use zstyle -e and do something dynamic. the fake-always style could also be used, see zshcompsys(1) about them.
even more fancy things can be accomplished when used with tag-order for a command. like grouping hosts by domain name or other arbitrary ways.

>   * If `reply` executes any function or binary under the hood, the terminal hangs after each <tab> pressing.
Assuming you are referring to the above zstyle -e example, it waits for the command to finish, it should only
"hang" if the command being executed does so. executing something that is slow is probably not a smart idea in
general if you are expecting fast results.

Re: Questions regarding _hosts completion extension

[Bart Schaefer]

On Mon, Jun 27, 2022 at 2:37 PM Mikhail f. Shiryaev
<mr.felixoid@gmail.com> 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.