From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 25103 invoked from network); 27 Jun 2022 21:37:44 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 27 Jun 2022 21:37:44 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1656365864; b=N/Z+Gx0u8WMd5loYQnZTzENYYo9rVnZQgFHnV7LYBOpXtWR0y/afeDaZtAXQiTJ/2nC6aHFe3p X+PoEf39nYzE2q4lRHfrNWcJUFuWCus+7ARZKGdAgROQVuM9D5kObgmy7jOhOH7nCQCe9+nb/W Lt9tG9l/VeMlTtZt3/UzCURVaNxBsSBST/mbY7OW/1VbzHs7vYgHhkisXXIp9+OoOMaLQhUzuu 6WIoHssLgCSxueNxiR7OOiOKPouLWrMONW2wfAm/V6nL/wBF97Y0t+/yFZhzVGxK7aOQkYvt0U ysyPs/WTTW5cg5XgJLYodSV92ZMVWlU5QOnQa5P3AqIIeg==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (mail-ej1-f46.google.com) smtp.remote-ip=209.85.218.46; dkim=pass header.d=gmail.com header.s=20210112 header.a=rsa-sha256; dmarc=pass header.from=gmail.com; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20210803; t=1656365864; bh=xrFFJCv24MbEDr46vcjh5l7BBS7qnYhQqriCrk3f84I=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:Content-Type:To:Subject:Message-ID:Date:From:MIME-Version: DKIM-Signature:DKIM-Signature; b=C6LvGkUNKPzh2n1U08QYEHz+NNBQ/ECuGsvV/rQgUlwFm6bHBCqDOFPjXJ58mw7lBAJT6XIw79 ws5OtAt+Crr6D2QRZbhniXOuJjmlwtlCyOan2iwcUQXAeF3W0aE3ayxrvb+U8NUWcoRSqAim9n /mB0uEh5Yp8baG09kGSP+2cHTYjnLNUlVh4y2rZz0P0ocJIuvKXiPmS/kOM5WLcl8Q6O092Is+ +7e/cicjUEEmF1inzJlJtj2cmkme3R0XQk2dvfxTFQ++817+7q0VCa1JqLvsgu2HN5iHPNadiq N+xu00C7Z9RX8qz9LjkGjyGMwytGwVP3U6E/FbhqTGtfww==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20210803; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:Content-Type:To:Subject:Message-ID: Date:From:MIME-Version:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References; bh=ZdUS7zdGFUBBUCoMmr+5iLGsuXSsAr0KkDRRfdGVNUE=; b=fNrIPKcTSRMZFebg0sR40rVjWa 3qtzzL38VpCImzrngAyrazppNofQlzO3sljhKwkgqOE1J4nRjCyPvWJIhji9aZtQJrGOUvvFquLDB Ub5oOlkDTcERkND5iAs8UJBtF1b9Q6lE4bXGaDsxoUGhLAylDRkUZa47jiZp8YqUIDABgtkL+Cuvr 5UdxlyHXF8Gtu+2NC1Y7m0cy3ILdAL5kG92JPRAKcvxGpr78TaQ78SYR7Y7iTY5P548GH476RNGrZ VjwraPOLqgMD5AjTbXO3sh/jehaBzIBXD4puxF8ylVtxQhnG2n+UZGyWP9FFUXRF8VCOpIE228A0i kFhb+DPQ==; Received: from authenticated user by zero.zsh.org with local id 1o5wQS-00080S-Nh; Mon, 27 Jun 2022 21:37:44 +0000 Authentication-Results: zsh.org; iprev=pass (mail-ej1-f46.google.com) smtp.remote-ip=209.85.218.46; dkim=pass header.d=gmail.com header.s=20210112 header.a=rsa-sha256; dmarc=pass header.from=gmail.com; arc=none Received: from mail-ej1-f46.google.com ([209.85.218.46]:42521) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1o5wQD-0007gM-Cd; Mon, 27 Jun 2022 21:37:30 +0000 Received: by mail-ej1-f46.google.com with SMTP id fi2so21793298ejb.9 for ; Mon, 27 Jun 2022 14:37:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=ZdUS7zdGFUBBUCoMmr+5iLGsuXSsAr0KkDRRfdGVNUE=; b=RB+NUho3dbV1Wr9Hla8LZe3fFgQLzGMBPfIwRHfqW8mUewtdY/MsU7/CFh7bsMXm1g rCBR7lqXFFrE8R1GHD9W/31KUxSyKsQnN6ii7AStIgcFOCt1Xm0LVLc4yIBlkBZoDMUL Ki82r1H/LEximjb8dzyuXP/wtzU06wlrBzjcnsWOmPUys9cKkjQDUjvA0ohxl/UoubMw t40rbCLOnlGwFrXVLOp/vItqrU2eeFBj/Uo8blDVQVlVmrf+Fo38SCLswv70ug5cRlNZ D4VeyvRPvlrkOHHRWOPtJ6GG4UoDbTgyhsFxAup/BfsARBHaZlHTlvbY8HgcYoSVCC8X Xa6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ZdUS7zdGFUBBUCoMmr+5iLGsuXSsAr0KkDRRfdGVNUE=; b=n26i0bbAMGs0dEH5+Uzl5iYyjBmsmSLbKKEMHTFXxc8AdyRUxnxl+k7sE/OIStkQQn Cns8Qeb6AI5qCDUycM4ipxKHnCpauIvw68jwASH1p2q/WAq7ojPj2QQcTOxtzlLYv5xf scj0Jgw7QkaH4tSQ7Vx1XdYlfb+Vet5vIBHuQDhlrKmoxnxqe66o2/7NUFA5lAJRhomg V9MFoDZnGlITnmpjIEzm/vRJedjGd/1UkY6Y4IcVSVSNEtBdDLonIjKmaqgvodZ+cY4l uZpPFZO+pknvTrTcD87iZVK/Xl3stt8HnxlcFqkcLfMK94kDiVNpJcV3G9L3d0aSmi1s VXfg== X-Gm-Message-State: AJIora+KpeQfF+KBuJ0Z6oBNJzlr8YC3Og9K1iACzyYiXhcJnyiqEo4U WT1JAMJLuC0xBZ5FA5asvFMBxq6A/J31bIqjyYSEntVB X-Google-Smtp-Source: AGRyM1vp1k9dJaSPJT8i/N12AqVt2Aw02mM0A8XId2CsV9NeKHJ32Fwq3CMALCeXyUtZxtsFL6U3HS0pIZx1EZxqefQ= X-Received: by 2002:a17:907:7251:b0:723:dc32:aefb with SMTP id ds17-20020a170907725100b00723dc32aefbmr14340781ejc.91.1656365848523; Mon, 27 Jun 2022 14:37:28 -0700 (PDT) MIME-Version: 1.0 From: "Mikhail f. Shiryaev" Date: Mon, 27 Jun 2022 23:37:02 +0200 Message-ID: Subject: Questions regarding _hosts completion extension To: zsh-workers@zsh.org Content-Type: multipart/alternative; boundary="00000000000004f77905e274ba2a" X-Seq: 50387 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: List-Archive: --00000000000004f77905e274ba2a Content-Type: text/plain; charset="UTF-8" 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 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 --00000000000004f77905e274ba2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello dear workers,
I have some questions r= egarding a stock _hosts completion function.

The o= riginal function, IMHO, has a few flaws that kind of difficult to address w= ithout a heavy development, in particular:
  • It doesn't= use cache features, so the shell instances don't share the state betwe= en them
  • It fills up the _cache_hosts only once at the first complet= ion, 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 ':completi= on:*:hosts' hosts 'reply=3D(...)`. Unfortunately, it completely ove= rrides the original function.
  • If `reply` executes any function or b= inary 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. Featur= es it has:
  • Users can set HOCO_FUNCTIONS array. Then its o= utput will be split by spaces, tabs, and new lines, and used as the hosts&#= 39; completion.
  • Uses the cache functions _store_cache, _retriev= e_cache, and _cache_invalid. The cache content is shared between instances = when `:completion:* use-cache` is set.
  • Functions or binaries are ex= ecuted in the background and don't block the terminal.

I'd like to ask about your opinion if it makes s= ense to bring it to the upstream. I am sure it still doesn't comply wit= h the requirements for 100% and can be improved. On the other hand, it brin= gs many advantages. I'd like to hear your opinion before trying to prep= are a patch if it completely breaks some rules though. For example, if asyn= c shouldn't be used in completion.

What do= you think?

Best regards,
=
M= ikhail f. Shiryaev
--00000000000004f77905e274ba2a--