Questions regarding _hosts completion extension

["Mikhail f. Shiryaev" <mr.felixoid@gmail.com>]

[-- 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 --]