unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#10539: 24.0.92; low display-time-interval makes Emacs slow
@ 2012-01-18  1:52 Michael Heerdegen
  2012-01-27 21:30 ` Glenn Morris
  2022-04-23 14:41 ` Lars Ingebrigtsen
  0 siblings, 2 replies; 25+ messages in thread
From: Michael Heerdegen @ 2012-01-18  1:52 UTC (permalink / raw)
  To: 10539

Hello,

in emacs -Q, set `display-time-interval' to 1 and enable
`display-time-mode'.

The docstring of `display-time-interval' says "Seconds between updates
of time in the mode line.".  Ok, fine.  The doc of
`display-time-string-forms' includes an example which makes
`display-time-mode' show seconds.  So, the user may think setting
`display-time-interval' to 1 is a good idea.

But it is currently not, on the contrary.

First of all, `display-time-update' is a long, complex function.
Running only its calculations every second consumes some percent CPU by
itself.

Second, the doc of `display-time-update' says

  Update the display-time info for the mode line.
  However, don't redisplay right now.

But it _does_ redisplay, it calls `force-mode-line-update' explicitly at
the end of the code!

If I redefine `display-time-update' so that it doesn't call
`force-mode-line-update', the update of the time in the mode-line
surprisingly still works, I get an update every second.  So, maybe the
call to `force-mode-line-update' can be removed.

Now I disable global font lock and such CPU eating minor mode stuff.  I
visit my ~/.newsrc.eld which has 647k.  My CPU consumption gets nearly
100%, it takes several seconds until q (`View-quit') gets processed.  If
I visit that file with `display-time-mode' off, that doesn't happen.

So, at the end, you could try to make `display-time-mode' more
effective.  If `display-time-update' does redisplay, then the doc should
say so.  And if we can't improve things, then the docstring of
`display-time-interval' should say that low values are 
deprecated because they decrease Emacs' performance.


Thanks,

Michael.



In GNU Emacs 24.0.92.1 (i486-pc-linux-gnu, GTK+ Version 3.2.3)
 of 2012-01-11 on zelenka, modified by Debian
 (emacs-snapshot package, version 1:20120111-1)
Windowing system distributor `The X.Org Foundation', version 11.0.11102902
configured using `configure  '--build' 'i486-linux-gnu' '--host' 'i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/24.0.92/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.0.92/site-lisp:/usr/share/emacs/site-lisp' '--without-compress-info' '--with-crt-dir=/usr/lib/i386-linux-gnu/' '--with-x=yes' '--with-x-toolkit=gtk3' '--with-imagemagick=yes' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2''

Important settings:
  value of $LC_ALL: de_DE.utf8
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: C
  value of $LANG: de_DE.utf8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t






^ permalink raw reply	[flat|nested] 25+ messages in thread

* bug#10539: 24.0.92; low display-time-interval makes Emacs slow
  2012-01-18  1:52 bug#10539: 24.0.92; low display-time-interval makes Emacs slow Michael Heerdegen
@ 2012-01-27 21:30 ` Glenn Morris
  2012-01-28  8:40   ` Eli Zaretskii
  2022-04-23 14:41 ` Lars Ingebrigtsen
  1 sibling, 1 reply; 25+ messages in thread
From: Glenn Morris @ 2012-01-27 21:30 UTC (permalink / raw)
  To: michael_heerdegen; +Cc: 10539

Michael Heerdegen wrote:

> Second, the doc of `display-time-update' says
>
>   Update the display-time info for the mode line.
>   However, don't redisplay right now.
>
> But it _does_ redisplay, it calls `force-mode-line-update' explicitly at
> the end of the code!

Looking at the history, the code used to have a (sit-for 0.0) after the
force-mode-line-update. The "don't redisplay" part was added when the
sit-for was removed. I confess that I don't really understand
force-mode-line-update [1]. The name makes sense, but not much else.
The manual says:

 -- Function: force-mode-line-update &optional all
     Force redisplay of the current buffer's mode line and header line.
     The next redisplay will update the mode line and header line based
     on the latest values of all relevant variables.

which seems contradictory to me ("force redisplay" + "next redisplay").

Maybe the "don't redisplay" refers to the lack of the ALL argument?


[1] eg http://lists.gnu.org/archive/html/emacs-devel/2010-05/msg00581.html





^ permalink raw reply	[flat|nested] 25+ messages in thread

* bug#10539: 24.0.92; low display-time-interval makes Emacs slow
  2012-01-27 21:30 ` Glenn Morris
@ 2012-01-28  8:40   ` Eli Zaretskii
  2012-01-28 11:07     ` martin rudalics
  2012-01-28 19:42     ` Glenn Morris
  0 siblings, 2 replies; 25+ messages in thread
From: Eli Zaretskii @ 2012-01-28  8:40 UTC (permalink / raw)
  To: Glenn Morris; +Cc: michael_heerdegen, 10539

> From: Glenn Morris <rgm@gnu.org>
> Date: Fri, 27 Jan 2012 16:30:44 -0500
> Cc: 10539@debbugs.gnu.org
> 
> Michael Heerdegen wrote:
> 
> > Second, the doc of `display-time-update' says
> >
> >   Update the display-time info for the mode line.
> >   However, don't redisplay right now.
> >
> > But it _does_ redisplay, it calls `force-mode-line-update' explicitly at
> > the end of the code!
> 
> Looking at the history, the code used to have a (sit-for 0.0) after the
> force-mode-line-update. The "don't redisplay" part was added when the
> sit-for was removed. I confess that I don't really understand
> force-mode-line-update [1]. The name makes sense, but not much else.

The discussion that you refer to was about the optional ALL argument.
It said nothing about force-mode-line-update itself or its effect,
apart of that.

> The manual says:
> 
>  -- Function: force-mode-line-update &optional all
>      Force redisplay of the current buffer's mode line and header line.
>      The next redisplay will update the mode line and header line based
>      on the latest values of all relevant variables.
> 
> which seems contradictory to me ("force redisplay" + "next redisplay").

Would the following wording make it less confusing/contradictory?

  Force next redisplay cycle to update the current buffer's mode line
  and header line, based on the latest values of all the relevant
  variables.

> Maybe the "don't redisplay" refers to the lack of the ALL argument?

No, it refers to the fact that force-mode-line-update does not trigger
redisplay, it just sets some internal variable that would force
recomputation and redisplay of the mode line during the next redisplay
cycle, whenever that happens.  IOW, it prevents Emacs from deciding
that nothing changed and therefore nothing on the screen should be
redrawn.





^ permalink raw reply	[flat|nested] 25+ messages in thread

* bug#10539: 24.0.92; low display-time-interval makes Emacs slow
  2012-01-28  8:40   ` Eli Zaretskii
@ 2012-01-28 11:07     ` martin rudalics
  2012-01-28 19:43       ` Glenn Morris
  2012-01-28 19:42     ` Glenn Morris
  1 sibling, 1 reply; 25+ messages in thread
From: martin rudalics @ 2012-01-28 11:07 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: michael_heerdegen, 10539

 > Would the following wording make it less confusing/contradictory?
 >
 >   Force next redisplay cycle to update the current buffer's mode line

A buffer doesn't have a mode or header line.  And a body like

   (if all (with-current-buffer (other-buffer)))
   (set-buffer-modified-p (buffer-modified-p)))

indicates that this function exclusively relies on obscure side effects
which are not documented anywhere.

martin





^ permalink raw reply	[flat|nested] 25+ messages in thread

* bug#10539: 24.0.92; low display-time-interval makes Emacs slow
  2012-01-28  8:40   ` Eli Zaretskii
  2012-01-28 11:07     ` martin rudalics
@ 2012-01-28 19:42     ` Glenn Morris
  2012-01-28 20:28       ` Eli Zaretskii
  1 sibling, 1 reply; 25+ messages in thread
From: Glenn Morris @ 2012-01-28 19:42 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: michael_heerdegen, 10539

Eli Zaretskii wrote:

> Would the following wording make it less confusing/contradictory?
>
>   Force next redisplay cycle to update the current buffer's mode line
>   and header line, based on the latest values of all the relevant
>   variables.

Yes thanks. Plus something similar for the function's doc-string.
So it doesn't actually "force redisplay", it just marks things to be
updated the next time redisplay happens to occur (?).





^ permalink raw reply	[flat|nested] 25+ messages in thread

* bug#10539: 24.0.92; low display-time-interval makes Emacs slow
  2012-01-28 11:07     ` martin rudalics
@ 2012-01-28 19:43       ` Glenn Morris
  0 siblings, 0 replies; 25+ messages in thread
From: Glenn Morris @ 2012-01-28 19:43 UTC (permalink / raw)
  To: martin rudalics; +Cc: michael_heerdegen, 10539

martin rudalics wrote:

> indicates that this function exclusively relies on obscure side effects
> which are not documented anywhere.

Yes, that was basically my point. Which is presumably why it does other
stuff that has no obvious relation to mode-lines ("forces recomputation
of the menu bar menus and the frame title"). But this is probably
off-topic for this report.





^ permalink raw reply	[flat|nested] 25+ messages in thread

* bug#10539: 24.0.92; low display-time-interval makes Emacs slow
  2012-01-28 19:42     ` Glenn Morris
@ 2012-01-28 20:28       ` Eli Zaretskii
  2012-01-28 20:51         ` Glenn Morris
  0 siblings, 1 reply; 25+ messages in thread
From: Eli Zaretskii @ 2012-01-28 20:28 UTC (permalink / raw)
  To: Glenn Morris; +Cc: michael_heerdegen, 10539

> From: Glenn Morris <rgm@gnu.org>
> Cc: michael_heerdegen@web.de,  10539@debbugs.gnu.org
> Date: Sat, 28 Jan 2012 14:42:18 -0500
> 
> Eli Zaretskii wrote:
> 
> > Would the following wording make it less confusing/contradictory?
> >
> >   Force next redisplay cycle to update the current buffer's mode line
> >   and header line, based on the latest values of all the relevant
> >   variables.
> 
> Yes thanks. Plus something similar for the function's doc-string.

Will do.

> So it doesn't actually "force redisplay", it just marks things to be
> updated the next time redisplay happens to occur (?).

Yes, exactly.





^ permalink raw reply	[flat|nested] 25+ messages in thread

* bug#10539: 24.0.92; low display-time-interval makes Emacs slow
  2012-01-28 20:28       ` Eli Zaretskii
@ 2012-01-28 20:51         ` Glenn Morris
  2012-01-28 21:29           ` Eli Zaretskii
  0 siblings, 1 reply; 25+ messages in thread
From: Glenn Morris @ 2012-01-28 20:51 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: michael_heerdegen, 10539

Eli Zaretskii wrote:

>> So it doesn't actually "force redisplay", it just marks things to be
>> updated the next time redisplay happens to occur (?).
>
> Yes, exactly.

Thanks. Next question that occurs: the display-time stuff is a global
indicator that, when it needs updating, should be updated in all visible
mode-lines. So how does (force-mode-line-update) with no ALL argument do
anything useful in this case?





^ permalink raw reply	[flat|nested] 25+ messages in thread

* bug#10539: 24.0.92; low display-time-interval makes Emacs slow
  2012-01-28 20:51         ` Glenn Morris
@ 2012-01-28 21:29           ` Eli Zaretskii
  2012-01-29  6:07             ` Glenn Morris
  2012-01-29 17:51             ` martin rudalics
  0 siblings, 2 replies; 25+ messages in thread
From: Eli Zaretskii @ 2012-01-28 21:29 UTC (permalink / raw)
  To: Glenn Morris; +Cc: michael_heerdegen, 10539

> From: Glenn Morris <rgm@gnu.org>
> Cc: michael_heerdegen@web.de,  10539@debbugs.gnu.org
> Date: Sat, 28 Jan 2012 15:51:54 -0500
> 
> Next question that occurs: the display-time stuff is a global
> indicator that, when it needs updating, should be updated in all visible
> mode-lines. So how does (force-mode-line-update) with no ALL argument do
> anything useful in this case?

I think force-mode-line-update nowadays always forces update of all
visible mode lines, not just the one of the current buffer.

Calling force-mode-line-update with ALL non-nil forces a more thorough
redisplay (because it sets a flag which causes redisplay not to trust
the contents of the displayed windows, not just their mode lines).

IOW, (force-mode-line-update t) is a way to force the next redisplay
cycle do a more thorough job, it has nothing to do with mode lines per
se.





^ permalink raw reply	[flat|nested] 25+ messages in thread

* bug#10539: 24.0.92; low display-time-interval makes Emacs slow
  2012-01-28 21:29           ` Eli Zaretskii
@ 2012-01-29  6:07             ` Glenn Morris
  2012-01-29 16:07               ` Drew Adams
  2012-01-29 17:11               ` Eli Zaretskii
  2012-01-29 17:51             ` martin rudalics
  1 sibling, 2 replies; 25+ messages in thread
From: Glenn Morris @ 2012-01-29  6:07 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: michael_heerdegen, 10539

Eli Zaretskii wrote:

> I think force-mode-line-update nowadays always forces update of all
> visible mode lines, not just the one of the current buffer.
>
> Calling force-mode-line-update with ALL non-nil forces a more thorough
> redisplay (because it sets a flag which causes redisplay not to trust
> the contents of the displayed windows, not just their mode lines).
>
> IOW, (force-mode-line-update t) is a way to force the next redisplay
> cycle do a more thorough job, it has nothing to do with mode lines per
> se.

I think it would be good if you could document this, because it's
basically impossible to figure out what this function actually does from
looking at its lisp definition.





^ permalink raw reply	[flat|nested] 25+ messages in thread

* bug#10539: 24.0.92; low display-time-interval makes Emacs slow
  2012-01-29  6:07             ` Glenn Morris
@ 2012-01-29 16:07               ` Drew Adams
  2012-01-29 17:11               ` Eli Zaretskii
  1 sibling, 0 replies; 25+ messages in thread
From: Drew Adams @ 2012-01-29 16:07 UTC (permalink / raw)
  To: 'Glenn Morris', 'Eli Zaretskii'; +Cc: michael_heerdegen, 10539

> > IOW, (force-mode-line-update t) is a way to force the next redisplay
> > cycle do a more thorough job, it has nothing to do with mode lines per
> > se.
> 
> I think it would be good if you could document this, because it's
> basically impossible to figure out what this function 
> actually does from looking at its lisp definition.

+1






^ permalink raw reply	[flat|nested] 25+ messages in thread

* bug#10539: 24.0.92; low display-time-interval makes Emacs slow
  2012-01-29  6:07             ` Glenn Morris
  2012-01-29 16:07               ` Drew Adams
@ 2012-01-29 17:11               ` Eli Zaretskii
  2012-01-30  4:40                 ` Stefan Monnier
  1 sibling, 1 reply; 25+ messages in thread
From: Eli Zaretskii @ 2012-01-29 17:11 UTC (permalink / raw)
  To: Glenn Morris; +Cc: michael_heerdegen, 10539

> From: Glenn Morris <rgm@gnu.org>
> Cc: michael_heerdegen@web.de,  10539@debbugs.gnu.org
> Date: Sun, 29 Jan 2012 01:07:24 -0500
> 
> Eli Zaretskii wrote:
> 
> > I think force-mode-line-update nowadays always forces update of all
> > visible mode lines, not just the one of the current buffer.
> >
> > Calling force-mode-line-update with ALL non-nil forces a more thorough
> > redisplay (because it sets a flag which causes redisplay not to trust
> > the contents of the displayed windows, not just their mode lines).
> >
> > IOW, (force-mode-line-update t) is a way to force the next redisplay
> > cycle do a more thorough job, it has nothing to do with mode lines per
> > se.
> 
> I think it would be good if you could document this, because it's
> basically impossible to figure out what this function actually does from
> looking at its lisp definition.

I don't mind, but I'd like Chong's and Stefan's opinion on this first.
The way the function is (was) implemented it exploits intimate
knowledge about redisplay's inner workings.  Maybe we should simply
expose to Lisp the corresponding internal variables instead, or
provide Lisp primitive functions to set them?





^ permalink raw reply	[flat|nested] 25+ messages in thread

* bug#10539: 24.0.92; low display-time-interval makes Emacs slow
  2012-01-28 21:29           ` Eli Zaretskii
  2012-01-29  6:07             ` Glenn Morris
@ 2012-01-29 17:51             ` martin rudalics
  2012-01-29 18:26               ` Eli Zaretskii
  1 sibling, 1 reply; 25+ messages in thread
From: martin rudalics @ 2012-01-29 17:51 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: michael_heerdegen, 10539

 > Calling force-mode-line-update with ALL non-nil forces a more thorough
 > redisplay (because it sets a flag which causes redisplay not to trust
 > the contents of the displayed windows, not just their mode lines).

Can you tell me which flag (with-current-buffer (other-buffer)) sets?

martin





^ permalink raw reply	[flat|nested] 25+ messages in thread

* bug#10539: 24.0.92; low display-time-interval makes Emacs slow
  2012-01-29 17:51             ` martin rudalics
@ 2012-01-29 18:26               ` Eli Zaretskii
  2012-01-30 10:20                 ` martin rudalics
  0 siblings, 1 reply; 25+ messages in thread
From: Eli Zaretskii @ 2012-01-29 18:26 UTC (permalink / raw)
  To: martin rudalics; +Cc: michael_heerdegen, 10539

> Date: Sun, 29 Jan 2012 18:51:42 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: Glenn Morris <rgm@gnu.org>, michael_heerdegen@web.de, 
>  10539@debbugs.gnu.org
> 
>  > Calling force-mode-line-update with ALL non-nil forces a more thorough
>  > redisplay (because it sets a flag which causes redisplay not to trust
>  > the contents of the displayed windows, not just their mode lines).
> 
> Can you tell me which flag (with-current-buffer (other-buffer)) sets?

windows_or_buffers_changed, AFAIR.





^ permalink raw reply	[flat|nested] 25+ messages in thread

* bug#10539: 24.0.92; low display-time-interval makes Emacs slow
  2012-01-29 17:11               ` Eli Zaretskii
@ 2012-01-30  4:40                 ` Stefan Monnier
  2012-01-30 17:44                   ` Eli Zaretskii
  0 siblings, 1 reply; 25+ messages in thread
From: Stefan Monnier @ 2012-01-30  4:40 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: michael_heerdegen, 10539

> I don't mind, but I'd like Chong's and Stefan's opinion on this first.
> The way the function is (was) implemented it exploits intimate
> knowledge about redisplay's inner workings.  Maybe we should simply
> expose to Lisp the corresponding internal variables instead, or
> provide Lisp primitive functions to set them?

I don't mind the current code, but it deserves a comment pointing to the
corresponding part of the C code that is affected.


        Stefan





^ permalink raw reply	[flat|nested] 25+ messages in thread

* bug#10539: 24.0.92; low display-time-interval makes Emacs slow
  2012-01-29 18:26               ` Eli Zaretskii
@ 2012-01-30 10:20                 ` martin rudalics
  2012-01-30 18:02                   ` Eli Zaretskii
  0 siblings, 1 reply; 25+ messages in thread
From: martin rudalics @ 2012-01-30 10:20 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: michael_heerdegen, 10539

 >> Can you tell me which flag (with-current-buffer (other-buffer)) sets?
 >
 > windows_or_buffers_changed, AFAIR.

(with-current-buffer (other-buffer)) does neither change the contents of
a window nor those of a buffer (unless it recreates *scratch*).

martin





^ permalink raw reply	[flat|nested] 25+ messages in thread

* bug#10539: 24.0.92; low display-time-interval makes Emacs slow
  2012-01-30  4:40                 ` Stefan Monnier
@ 2012-01-30 17:44                   ` Eli Zaretskii
  2012-01-30 22:01                     ` Stefan Monnier
  0 siblings, 1 reply; 25+ messages in thread
From: Eli Zaretskii @ 2012-01-30 17:44 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: michael_heerdegen, 10539

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Glenn Morris <rgm@gnu.org>,  michael_heerdegen@web.de,  10539@debbugs.gnu.org
> Date: Sun, 29 Jan 2012 23:40:29 -0500
> 
> > I don't mind, but I'd like Chong's and Stefan's opinion on this first.
> > The way the function is (was) implemented it exploits intimate
> > knowledge about redisplay's inner workings.  Maybe we should simply
> > expose to Lisp the corresponding internal variables instead, or
> > provide Lisp primitive functions to set them?
> 
> I don't mind the current code, but it deserves a comment pointing to the
> corresponding part of the C code that is affected.

The two internal variables in question (update_mode_lines and
windows_or_buffers_changed) affect many parts of the display code, and
also appear in buffer.c, window.c, and a bunch of other files.  Just
grep for them, they are all over the place.

So I'm unsure what you mean by "corresponding part of the C code".





^ permalink raw reply	[flat|nested] 25+ messages in thread

* bug#10539: 24.0.92; low display-time-interval makes Emacs slow
  2012-01-30 10:20                 ` martin rudalics
@ 2012-01-30 18:02                   ` Eli Zaretskii
  2012-01-30 18:13                     ` martin rudalics
  0 siblings, 1 reply; 25+ messages in thread
From: Eli Zaretskii @ 2012-01-30 18:02 UTC (permalink / raw)
  To: martin rudalics; +Cc: michael_heerdegen, 10539

> Date: Mon, 30 Jan 2012 11:20:16 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: rgm@gnu.org, michael_heerdegen@web.de, 10539@debbugs.gnu.org
> 
>  >> Can you tell me which flag (with-current-buffer (other-buffer)) sets?
>  >
>  > windows_or_buffers_changed, AFAIR.
> 
> (with-current-buffer (other-buffer)) does neither change the contents of
> a window nor those of a buffer (unless it recreates *scratch*).

Sorry, I don't understand what you are trying to convey.





^ permalink raw reply	[flat|nested] 25+ messages in thread

* bug#10539: 24.0.92; low display-time-interval makes Emacs slow
  2012-01-30 18:02                   ` Eli Zaretskii
@ 2012-01-30 18:13                     ` martin rudalics
  2012-01-30 19:04                       ` Eli Zaretskii
  0 siblings, 1 reply; 25+ messages in thread
From: martin rudalics @ 2012-01-30 18:13 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: michael_heerdegen, 10539

 >>  >> Can you tell me which flag (with-current-buffer (other-buffer)) sets?
 >>  >
 >>  > windows_or_buffers_changed, AFAIR.
 >>
 >> (with-current-buffer (other-buffer)) does neither change the contents of
 >> a window nor those of a buffer (unless it recreates *scratch*).
 >
 > Sorry, I don't understand what you are trying to convey.

If I understand windows_or_buffers_changed correctly, it is only set
when either a window changes (resized, another buffer displayed in it,
...) or a buffer is changed (text inserted, `point' changes, ...).
Neither `with-current-buffer' nor `other-buffer' change a window or a
buffer.  What am I missing?

martin





^ permalink raw reply	[flat|nested] 25+ messages in thread

* bug#10539: 24.0.92; low display-time-interval makes Emacs slow
  2012-01-30 18:13                     ` martin rudalics
@ 2012-01-30 19:04                       ` Eli Zaretskii
  0 siblings, 0 replies; 25+ messages in thread
From: Eli Zaretskii @ 2012-01-30 19:04 UTC (permalink / raw)
  To: martin rudalics; +Cc: michael_heerdegen, 10539

> Date: Mon, 30 Jan 2012 19:13:08 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: rgm@gnu.org, michael_heerdegen@web.de, 10539@debbugs.gnu.org
> 
> Neither `with-current-buffer' nor `other-buffer' change a window or a
> buffer.  What am I missing?

At least at some point they did.  I will have to run Emacs under a
debugger to refresh my faulting memory.





^ permalink raw reply	[flat|nested] 25+ messages in thread

* bug#10539: 24.0.92; low display-time-interval makes Emacs slow
  2012-01-30 17:44                   ` Eli Zaretskii
@ 2012-01-30 22:01                     ` Stefan Monnier
  2012-01-31  3:48                       ` Eli Zaretskii
  0 siblings, 1 reply; 25+ messages in thread
From: Stefan Monnier @ 2012-01-30 22:01 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: michael_heerdegen, 10539

>> > I don't mind, but I'd like Chong's and Stefan's opinion on this first.
>> > The way the function is (was) implemented it exploits intimate
>> > knowledge about redisplay's inner workings.  Maybe we should simply
>> > expose to Lisp the corresponding internal variables instead, or
>> > provide Lisp primitive functions to set them?
>> I don't mind the current code, but it deserves a comment pointing to the
>> corresponding part of the C code that is affected.
> The two internal variables in question (update_mode_lines and
> windows_or_buffers_changed) affect many parts of the display code, and
> also appear in buffer.c, window.c, and a bunch of other files.  Just
> grep for them, they are all over the place.

Indeed, that's why a comment is needed: the corresponding info is not
easy to find.

> So I'm unsure what you mean by "corresponding part of the C code".

The corresponding parts would be:
1- the place where the C code (run via the Elisp code of
   force-mode-line-update) sets those vars.
2- the place in the C code where those vars are checked later on during
   redisplay so that they cause the mode-line to be refreshed.


        Stefan





^ permalink raw reply	[flat|nested] 25+ messages in thread

* bug#10539: 24.0.92; low display-time-interval makes Emacs slow
  2012-01-30 22:01                     ` Stefan Monnier
@ 2012-01-31  3:48                       ` Eli Zaretskii
  0 siblings, 0 replies; 25+ messages in thread
From: Eli Zaretskii @ 2012-01-31  3:48 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: michael_heerdegen, 10539

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: rgm@gnu.org, michael_heerdegen@web.de, 10539@debbugs.gnu.org
> Date: Mon, 30 Jan 2012 17:01:53 -0500
> 
> The corresponding parts would be:
> 1- the place where the C code (run via the Elisp code of
>    force-mode-line-update) sets those vars.
> 2- the place in the C code where those vars are checked later on during
>    redisplay so that they cause the mode-line to be refreshed.

OK, will do.





^ permalink raw reply	[flat|nested] 25+ messages in thread

* bug#10539: 24.0.92; low display-time-interval makes Emacs slow
  2012-01-18  1:52 bug#10539: 24.0.92; low display-time-interval makes Emacs slow Michael Heerdegen
  2012-01-27 21:30 ` Glenn Morris
@ 2022-04-23 14:41 ` Lars Ingebrigtsen
  2022-04-30  1:12   ` Michael Heerdegen
  1 sibling, 1 reply; 25+ messages in thread
From: Lars Ingebrigtsen @ 2022-04-23 14:41 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: 10539

Michael Heerdegen <michael_heerdegen@web.de> writes:

> The docstring of `display-time-interval' says "Seconds between updates
> of time in the mode line.".  Ok, fine.  The doc of
> `display-time-string-forms' includes an example which makes
> `display-time-mode' show seconds.  So, the user may think setting
> `display-time-interval' to 1 is a good idea.
>
> But it is currently not, on the contrary.
>
> First of all, `display-time-update' is a long, complex function.
> Running only its calculations every second consumes some percent CPU by
> itself.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

I've tried this in Emacs 29, and the Emacs in question does not show up
on "top" as consuming any CPU, so this has perhaps improved?

> Second, the doc of `display-time-update' says
>
>   Update the display-time info for the mode line.
>   However, don't redisplay right now.
>
> But it _does_ redisplay, it calls `force-mode-line-update' explicitly at
> the end of the code!

As noted in the bug thread, `force-mode-line-update' just sets some
variables to make the next redisplay cycle update the mode lines, so
the doc string is correct, I think.

The discussion then went on to adding some more comments or something,
but I'm not sure whether there's anything more to be done here?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 25+ messages in thread

* bug#10539: 24.0.92; low display-time-interval makes Emacs slow
  2022-04-23 14:41 ` Lars Ingebrigtsen
@ 2022-04-30  1:12   ` Michael Heerdegen
  2022-04-30 11:46     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 25+ messages in thread
From: Michael Heerdegen @ 2022-04-30  1:12 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 10539

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I've tried this in Emacs 29, and the Emacs in question does not show
> up on "top" as consuming any CPU, so this has perhaps improved?

Maybe, I dunno. Everything currently looks quite sane here, no problem.

> As noted in the bug thread, `force-mode-line-update' just sets some
> variables to make the next redisplay cycle update the mode lines, so
> the doc string is correct, I think.

Probably right.

> The discussion then went on to adding some more comments or something,
> but I'm not sure whether there's anything more to be done here?

I haven't checked if everyone has committed every suggested aspect of
improvements to the docs.  If nobody else answers, you might close, from
my side.

Thanks,

Michael.





^ permalink raw reply	[flat|nested] 25+ messages in thread

* bug#10539: 24.0.92; low display-time-interval makes Emacs slow
  2022-04-30  1:12   ` Michael Heerdegen
@ 2022-04-30 11:46     ` Lars Ingebrigtsen
  0 siblings, 0 replies; 25+ messages in thread
From: Lars Ingebrigtsen @ 2022-04-30 11:46 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: 10539

Michael Heerdegen <michael_heerdegen@web.de> writes:

> I haven't checked if everyone has committed every suggested aspect of
> improvements to the docs.  If nobody else answers, you might close, from
> my side.

OK; closing.  (If somebody else responds and feels there more to be done
here, we'll reopen.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 25+ messages in thread

end of thread, other threads:[~2022-04-30 11:46 UTC | newest]

Thread overview: 25+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-01-18  1:52 bug#10539: 24.0.92; low display-time-interval makes Emacs slow Michael Heerdegen
2012-01-27 21:30 ` Glenn Morris
2012-01-28  8:40   ` Eli Zaretskii
2012-01-28 11:07     ` martin rudalics
2012-01-28 19:43       ` Glenn Morris
2012-01-28 19:42     ` Glenn Morris
2012-01-28 20:28       ` Eli Zaretskii
2012-01-28 20:51         ` Glenn Morris
2012-01-28 21:29           ` Eli Zaretskii
2012-01-29  6:07             ` Glenn Morris
2012-01-29 16:07               ` Drew Adams
2012-01-29 17:11               ` Eli Zaretskii
2012-01-30  4:40                 ` Stefan Monnier
2012-01-30 17:44                   ` Eli Zaretskii
2012-01-30 22:01                     ` Stefan Monnier
2012-01-31  3:48                       ` Eli Zaretskii
2012-01-29 17:51             ` martin rudalics
2012-01-29 18:26               ` Eli Zaretskii
2012-01-30 10:20                 ` martin rudalics
2012-01-30 18:02                   ` Eli Zaretskii
2012-01-30 18:13                     ` martin rudalics
2012-01-30 19:04                       ` Eli Zaretskii
2022-04-23 14:41 ` Lars Ingebrigtsen
2022-04-30  1:12   ` Michael Heerdegen
2022-04-30 11:46     ` Lars Ingebrigtsen

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).