GNU bug report logs -
#10539
24.0.92; low display-time-interval makes Emacs slow
Previous Next
Reported by: michael_heerdegen <at> web.de
Date: Wed, 18 Jan 2012 01:52:01 UTC
Severity: minor
Tags: moreinfo
Found in version 24.0.92
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10539 in the body.
You can then email your comments to 10539 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10539
; Package
emacs
.
(Wed, 18 Jan 2012 01:52:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
michael_heerdegen <at> web.de
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Wed, 18 Jan 2012 01:52:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10539
; Package
emacs
.
(Fri, 27 Jan 2012 21:32:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 10539 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10539
; Package
emacs
.
(Sat, 28 Jan 2012 08:44:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 10539 <at> debbugs.gnu.org (full text, mbox):
> From: Glenn Morris <rgm <at> gnu.org>
> Date: Fri, 27 Jan 2012 16:30:44 -0500
> Cc: 10539 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10539
; Package
emacs
.
(Sat, 28 Jan 2012 11:09:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 10539 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10539
; Package
emacs
.
(Sat, 28 Jan 2012 19:44:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 10539 <at> debbugs.gnu.org (full text, mbox):
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 (?).
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10539
; Package
emacs
.
(Sat, 28 Jan 2012 19:45:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 10539 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10539
; Package
emacs
.
(Sat, 28 Jan 2012 20:32:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 10539 <at> debbugs.gnu.org (full text, mbox):
> From: Glenn Morris <rgm <at> gnu.org>
> Cc: michael_heerdegen <at> web.de, 10539 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10539
; Package
emacs
.
(Sat, 28 Jan 2012 20:53:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 10539 <at> debbugs.gnu.org (full text, mbox):
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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10539
; Package
emacs
.
(Sat, 28 Jan 2012 21:32:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 10539 <at> debbugs.gnu.org (full text, mbox):
> From: Glenn Morris <rgm <at> gnu.org>
> Cc: michael_heerdegen <at> web.de, 10539 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10539
; Package
emacs
.
(Sun, 29 Jan 2012 06:08:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 10539 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10539
; Package
emacs
.
(Sun, 29 Jan 2012 16:08:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 10539 <at> debbugs.gnu.org (full text, mbox):
> > 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10539
; Package
emacs
.
(Sun, 29 Jan 2012 17:15:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 10539 <at> debbugs.gnu.org (full text, mbox):
> From: Glenn Morris <rgm <at> gnu.org>
> Cc: michael_heerdegen <at> web.de, 10539 <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10539
; Package
emacs
.
(Sun, 29 Jan 2012 17:54:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 10539 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10539
; Package
emacs
.
(Sun, 29 Jan 2012 18:29:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 10539 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 29 Jan 2012 18:51:42 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: Glenn Morris <rgm <at> gnu.org>, michael_heerdegen <at> web.de,
> 10539 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10539
; Package
emacs
.
(Mon, 30 Jan 2012 04:41:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 10539 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10539
; Package
emacs
.
(Mon, 30 Jan 2012 10:22:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 10539 <at> debbugs.gnu.org (full text, mbox):
>> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10539
; Package
emacs
.
(Mon, 30 Jan 2012 17:47:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 10539 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Glenn Morris <rgm <at> gnu.org>, michael_heerdegen <at> web.de, 10539 <at> 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".
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10539
; Package
emacs
.
(Mon, 30 Jan 2012 18:05:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 10539 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 30 Jan 2012 11:20:16 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: rgm <at> gnu.org, michael_heerdegen <at> web.de, 10539 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10539
; Package
emacs
.
(Mon, 30 Jan 2012 18:15:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 10539 <at> debbugs.gnu.org (full text, mbox):
>> >> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10539
; Package
emacs
.
(Mon, 30 Jan 2012 19:07:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 10539 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 30 Jan 2012 19:13:08 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: rgm <at> gnu.org, michael_heerdegen <at> web.de, 10539 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10539
; Package
emacs
.
(Mon, 30 Jan 2012 22:03:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 10539 <at> debbugs.gnu.org (full text, mbox):
>> > 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10539
; Package
emacs
.
(Tue, 31 Jan 2012 03:51:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 10539 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> Cc: rgm <at> gnu.org, michael_heerdegen <at> web.de, 10539 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10539
; Package
emacs
.
(Sat, 23 Apr 2022 14:42:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 10539 <at> debbugs.gnu.org (full text, mbox):
Michael Heerdegen <michael_heerdegen <at> 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
Added tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sat, 23 Apr 2022 14:43:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10539
; Package
emacs
.
(Sat, 30 Apr 2022 01:13:02 GMT)
Full text and
rfc822 format available.
Message #76 received at 10539 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10539
; Package
emacs
.
(Sat, 30 Apr 2022 11:48:01 GMT)
Full text and
rfc822 format available.
Message #79 received at 10539 <at> debbugs.gnu.org (full text, mbox):
Michael Heerdegen <michael_heerdegen <at> 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
bug closed, send any further explanations to
10539 <at> debbugs.gnu.org and michael_heerdegen <at> web.de
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sat, 30 Apr 2022 11:48:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 29 May 2022 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 45 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.