* Re: Completion and REPORTTIME
2012-09-20 12:57 Completion and REPORTTIME Julien Nicoulaud
@ 2012-09-20 14:12 ` Peter Stephenson
2012-09-20 14:20 ` Mikael Magnusson
2012-09-20 14:15 ` Bart Schaefer
1 sibling, 1 reply; 5+ messages in thread
From: Peter Stephenson @ 2012-09-20 14:12 UTC (permalink / raw)
To: Mailing-list zsh-workers
On Thu, 20 Sep 2012 14:57:19 +0200
Julien Nicoulaud <julien.nicoulaud@gmail.com> 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 ?
As it's dumped straight to stderr, it's hard to see any point in having
it output automatically from any zle code.
Index: Doc/Zsh/params.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/params.yo,v
retrieving revision 1.70
diff -p -u -r1.70 params.yo
--- Doc/Zsh/params.yo 15 Jun 2012 21:22:36 -0000 1.70
+++ Doc/Zsh/params.yo 20 Sep 2012 14:10:47 -0000
@@ -1225,7 +1225,10 @@ vindex(REPORTTIME)
item(tt(REPORTTIME))(
If nonnegative, commands whose combined user and system execution times
(measured in seconds) are greater than this value have timing
-statistics printed for them.
+statistics printed for them. Output is surpressed for commands
+executed within the line editor, including completion; commands
+explicitly marked with the tt(time) keyword still cause the summary
+to be printed in this case.
)
vindex(REPLY)
item(tt(REPLY))(
Index: Src/jobs.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/jobs.c,v
retrieving revision 1.90
diff -p -u -r1.90 jobs.c
--- Src/jobs.c 22 May 2012 08:57:23 -0000 1.90
+++ Src/jobs.c 20 Sep 2012 14:10:47 -0000
@@ -868,6 +868,8 @@ should_report_time(Job j)
/* can this ever happen? */
if (!j->procs)
return 0;
+ if (zleactive)
+ return 0;
#ifdef HAVE_GETRUSAGE
reporttime -= j->procs->ti.ru_utime.tv_sec + j->procs->ti.ru_stime.tv_sec;
--
Peter Stephenson <pws@csr.com> Software Engineer
Tel: +44 (0)1223 692070 Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: Completion and REPORTTIME
2012-09-20 12:57 Completion and REPORTTIME Julien Nicoulaud
2012-09-20 14:12 ` Peter Stephenson
@ 2012-09-20 14:15 ` Bart Schaefer
2012-09-20 14:26 ` Peter Stephenson
1 sibling, 1 reply; 5+ messages in thread
From: Bart Schaefer @ 2012-09-20 14:15 UTC (permalink / raw)
To: Mailing-list zsh-workers
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.
^ permalink raw reply [flat|nested] 5+ messages in thread