From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7658 invoked by alias); 30 Jan 2014 02:12:30 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 32322 Received: (qmail 11007 invoked from network); 30 Jan 2014 02:12: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: <140129181206.ZM22813@torch.brasslantern.com> Date: Wed, 29 Jan 2014 18:12:06 -0800 In-reply-to: <87eh3q3g63.fsf@lwm.klanderman.net> Comments: In reply to Greg Klanderman "Re: [Feature suggestion] (user configurable) timeout for generating completion lists" (Jan 29, 11:29am) References: <140122000435.ZM1516@torch.brasslantern.com> <140123171659.ZM19422@torch.brasslantern.com> <87iot91lp8.fsf@lwm.klanderman.net> <140125124934.ZM23767@torch.brasslantern.com> <87eh3q3g63.fsf@lwm.klanderman.net> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org, gak@klanderman.net Subject: Tests of interrupting completion, and completion_nostat_dirs MIME-version: 1.0 Content-type: text/plain; charset=us-ascii [> workers] On Jan 29, 11:29am, Greg Klanderman wrote: } Subject: Re: [Feature suggestion] (user configurable) timeout for generati } } >>>>> On January 25, 2014 Bart Schaefer wrote: } } > 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.) Incidentally, here's something I added to _main_complete to make this easier to test: ------------ diff --git a/Completion/Base/Core/_main_complete b/Completion/Base/Core/_main_complete index d6831b8..036f1d3 100644 --- a/Completion/Base/Core/_main_complete +++ b/Completion/Base/Core/_main_complete @@ -126,6 +126,11 @@ fi _completer_num=1 +# We assume localtraps to be in effect here ... +integer SECONDS=0 +trap 'zle -M "Killed by signal in ${funcstack[0]} after ${SECONDS}s"; + zle -R; return 130' INT QUIT + # Call the pre-functions. funcs=( "$compprefuncs[@]" ) ------------ Any objection to that being pushed to the master git? } Did you try a busy completion function, or external process? I tried _slow() { sleep 30; return 1 } and the infinite loop _slow() { while :; do read -E -k 1 -u 0 /dev/null; done return 1 } and even _slow() { SECONDS=0 while (( SECONDS < 30 )); do : ; done return 1 } and I was able to interrupt all of them. } In the original post it seemed that the slow call was probably reading } a large directory on a slow NFS mount. Yes, but both that and stat of an automount are going to be disk-wait blocking accesses to NFS. } I'll attach the patch below, if you'd be willing to incorporate } something like it let me know, I'd certainly prefer to have it part of } zsh. I would add documentation of course. Hmm, to include this I'd probably want completion_nostat_dirs to be an autoloaded parameter in the zsh/complete module or something like that. It doesn't have any of those right now (the magic parameters that are only valid inside completion widgets are a somewhat different beast) but there's no reason it couldn't. On the other hand ZLE_RPROMPT_INDENT is declared in the main shell even though it's used only by zsh/zle ... anybody else want to weigh in?