From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29866 invoked by alias); 20 Sep 2012 14:16:27 -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: 30688 Received: (qmail 5279 invoked from network); 20 Sep 2012 14:16:26 -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 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <120920071549.ZM26034@torch.brasslantern.com> Date: Thu, 20 Sep 2012 07:15:49 -0700 In-reply-to: Comments: In reply to Julien Nicoulaud "Completion and REPORTTIME" (Sep 20, 2:57pm) References: X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Mailing-list zsh-workers Subject: Re: Completion and REPORTTIME MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Sep 20, 2:57pm, Julien Nicoulaud wrote: } } When REPORTTIME, time can be reported on some slow compdefs, which kinda } breaks output. I think time reporting should be disabled in the context of } completion functions execution, don't you ? Hmm. We should add "local REPORTTIME=0" to _comp_setup in Completion/compinit, but that only helps for completions that go through _main_complete (which admittedly is most of them). It's not practical to make the low-level job control functions aware of the completion system in order to suppress this there, and a bit ugly to be simulating "local REPORTTIME" in the C code completion callbacks. I suppose a generic hook for modules to toggle off time reporting (and any other semi-automatic shell diagnostics) is a possibility. On the other hand, the time report is printed to standard error, and it has so far been the responsibility of the individual completers to do redirection of stderr when they might produce diagnostics that muddy up the display. This is a bit different because the diagnostic is from the shell itself and could affect any operation under the right set of circumstances. Perhaps the completion C entry point(s) should arrange to close/restore stderr ... I believe things like _complete_debug that do their own stderr manipulation would still work. But I'm not very excited about that idea, either.