From: "Jan D." <jan.h.d@swipnet.se>
Cc: rms@gnu.org
Subject: Old redisplay bug in xdisp.c, question about change
Date: Sun, 23 Mar 2003 23:01:37 +0100 (CET) [thread overview]
Message-ID: <200303232254.h2NMsobL004941@stubby.bodenonline.com> (raw)
Hello.
I was looking for a redisplay bug I thought was in the GTK parts. It turns
out that the bug is present in both the Motif and Lucid ports also.
To reproduce.
emacs -q --no-site-file
C-h i
Select a node with the mouse.
Sometimes the bug can be seen right here. The tool bar arrows for up
and next are still disabled. If they are disabled, do a Ctrl-l to fix.
Now press 'u' to go up. The next and up tool bar arrows are now enabled,
they shall be disabled. Again, Ctrl-l fixes it.
There seems to be a bit of race condition here, the bug does not always
show up.
I traced the origin to this change:
2002-03-26 Richard M. Stallman <rms@gnu.org>
* xdisp.c (update_menu_bar): Test only update_mode_lines;
The diff:
@@ -7435,8 +7438,14 @@
window = FRAME_SELECTED_WINDOW (f);
w = XWINDOW (window);
+#if 0 /* The if statement below this if statement used to include the
+ condition !NILP (w->update_mode_line), rather than using
+ update_mode_lines directly, and this if statement may have
+ been added to make that condition work. Now the if
+ statement below matches its comment, this isn't needed. */
if (update_mode_lines)
w->update_mode_line = Qt;
+#endif
if (FRAME_WINDOW_P (f)
?
@@ -7455,7 +7464,9 @@
the rest of the redisplay algorithm is about the same as
windows_or_buffers_changed anyway. */
if (windows_or_buffers_changed
- || !NILP (w->update_mode_line)
+ /* This used to test w->update_mode_line, but we believe
+ there is no need to recompute the menu in that case. */
+ || update_mode_lines
|| ((BUF_SAVE_MODIFF (XBUFFER (w->buffer))
< BUF_MODIFF (XBUFFER (w->buffer)))
!= !NILP (w->last_had_star))
The comments indicate that the menu does not need to be updated, but
apparently the tool bar is not updated either, because w->update_mode_line
is not set to Qt.
There seems to be no ill effects from reverting this change, but since I
don't know why it was made in the first place, I can not be sure.
Does anybody remember the reason for this change?
Thanks,
Jan D.
next reply other threads:[~2003-03-23 22:01 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-23 22:01 Jan D. [this message]
2003-03-24 19:27 ` Old redisplay bug in xdisp.c, question about change Richard Stallman
2003-03-25 19:23 ` Jan D.
2003-03-27 3:30 ` Richard Stallman
2003-03-27 17:40 ` Jan D.
-- strict thread matches above, loose matches on Subject: below --
2003-03-25 14:44 Marshall, Simon
2003-03-25 19:35 ` Jan D.
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=200303232254.h2NMsobL004941@stubby.bodenonline.com \
--to=jan.h.d@swipnet.se \
--cc=rms@gnu.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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.