zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: Mailing-list zsh-workers <zsh-workers@zsh.org>
Subject: Re: Completion and REPORTTIME
Date: Thu, 20 Sep 2012 07:15:49 -0700	[thread overview]
Message-ID: <120920071549.ZM26034@torch.brasslantern.com> (raw)
In-Reply-To: <CA+mcLN7+1OYxKkgTxS8bKO6eMZ_=OWaj=EuVPnC_70aDvzm++w@mail.gmail.com>

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.


  parent reply	other threads:[~2012-09-20 14:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-20 12:57 Julien Nicoulaud
2012-09-20 14:12 ` Peter Stephenson
2012-09-20 14:20   ` Mikael Magnusson
2012-09-20 14:15 ` Bart Schaefer [this message]
2012-09-20 14:26   ` Peter Stephenson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=120920071549.ZM26034@torch.brasslantern.com \
    --to=schaefer@brasslantern.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).