From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29851 invoked by alias); 24 Jan 2014 01:17:21 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 18353 Received: (qmail 14571 invoked from network); 24 Jan 2014 01:17:15 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 From: Bart Schaefer Message-id: <140123171659.ZM19422@torch.brasslantern.com> Date: Thu, 23 Jan 2014 17:16:59 -0800 In-reply-to: Comments: In reply to Nikolai Weibull "Re: [Feature suggestion] (user configurable) timeout for generating completion lists" (Jan 23, 1:04pm) References: <140122000435.ZM1516@torch.brasslantern.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Zsh Users Subject: Re: [Feature suggestion] (user configurable) timeout for generating completion lists MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Jan 23, 1:04pm, Nikolai Weibull wrote: } } Time to delegate completion to a subprocess? That'd make it possible } to use Zsh completions from outside the shell as well. I just knew someone was going to say this. Completion is very closely tied into ZLE, and ZLE is very closely tied into the shell. It's not going to turn into a readline library without a complete rewrite. On the other hand, the completion functions themselves are just shell code, so it's possible to almost arbitrarily replace stuff they do inside the shell with stuff that's done outside. The current set of functions in fact go to an inordinate amount of effort to do just the opposite, on the assumption that forking and reading from pipes is more expensive / time-consuming than doing internal string manipulation and globbing. Back on the first hand, you might not gain much, because the compsys model is to have the shell functions generate all possible strings in the correct category and then let the internals filter them against the contents of the command line. This is what allows some of the really powerful stuff like expanding c.u.q into comp.unix.questions. If you rely on an external process, you either lose that or duplicate the effort of calculating it. We've already seen the "do it externally" plan break down with the _git issue discussed in the thread leading up to zsh-users/18321 (about which we're sort of awaiting your input, Nikolai). However, there are schemes like Thiago Padilha's zpty-based approach that would allow a separate zsh to compute the completions in the background, which would in turn allow the foreground zsh to ignore the results if they didn't come back soon enough. This is potentially duplication of effort, and what you'd still lose there (unless you duplicate still more effort) is file-type-based coloring or tagging and the like, which depend, e.g., upon ZLE having examined the filesystem. But it's jumping the gun a little to discuss all of this before we even know what's really causing the issue.