From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4444 invoked by alias); 25 Jan 2014 20:50:06 -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: 18369 Received: (qmail 9772 invoked from network); 25 Jan 2014 20:49:50 -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: <140125124934.ZM23767@torch.brasslantern.com> Date: Sat, 25 Jan 2014 12:49:34 -0800 In-reply-to: <87iot91lp8.fsf@lwm.klanderman.net> Comments: In reply to Greg Klanderman "Re: [Feature suggestion] (user configurable) timeout for generating completion lists" (Jan 24, 9:46am) References: <140122000435.ZM1516@torch.brasslantern.com> <140123171659.ZM19422@torch.brasslantern.com> <87iot91lp8.fsf@lwm.klanderman.net> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-users@zsh.org Subject: Re: [Feature suggestion] (user configurable) timeout for generating completion lists MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Jan 24, 9:46am, Greg Klanderman wrote: } } For slow completion due to calling out to a separate process for } completions (_git comes to mind) if that is not currently } interruptible it seems like there might be some hope of adding a } timeout or ensuring C-c will interrupt. This is the thing I had a hard time reproducing. Even if I force the completion function to be very busy with a loop, I can interrupt it. (Oddly the value of $? is always 0 in _main_complete after I hit ^C, so I can't detect the signal and issue a message.) } The biggest problem I've had with completion being unresponsive was } due to automounts at work (currently have ~53k under a handful of } mount points). Using the fake-files zstyle mostly works until } completion tries to stat all those automounts I think this is analogous to the situation that started this thread. } to determine the file type in order to append a '/' or ' '. ... which is difficult to do if there's an external program doing the stat. Not impossible, but it means passing a lot of structured data through a pipe, which might slow down more common cases. (Maybe this is why Meino wants "find -print0 -ls". :-> ) } So locally I run zsh with a } small patch (to ztat()) that uses a shell variable to configure } automount roots under which all immediate entries are assumed to be } directories without stat'ing. Works great, though I don't think } several years ago you were willing to incorporate that into zsh. Doesn't sound terrible, but I don't think it would solve the original problem, which if I'm right is that NFS listing is big/slow after the mount is already completed.