all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Old redisplay bug in xdisp.c, question about change
@ 2003-03-23 22:01 Jan D.
  2003-03-24 19:27 ` Richard Stallman
  0 siblings, 1 reply; 7+ messages in thread
From: Jan D. @ 2003-03-23 22:01 UTC (permalink / raw)
  Cc: rms

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.

^ permalink raw reply	[flat|nested] 7+ messages in thread
* Re: Old redisplay bug in xdisp.c, question about change
@ 2003-03-25 14:44 Marshall, Simon
  2003-03-25 19:35 ` Jan D.
  0 siblings, 1 reply; 7+ messages in thread
From: Marshall, Simon @ 2003-03-25 14:44 UTC (permalink / raw)
  Cc: 'emacs-devel@gnu.org'

	    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?

	I think I made this change just as an optimization.  So it could
be
	reverted safely.

	Another alternative is to execute, in that case,
	just the parts of the if-statement that are really needed in
that case.

This particular change was part of a group of changes made to prevent or
reduce multiple unnecessary runs of menu-bar-update-hook on things like
scrolls, tooltips, mouse-1 with mouse-sel-mode, C-s, C-x 2 or menu-bar
clicks.  (The performance impact is so bad that I use 21.1.90 + these
changes for all my editing, rather than 21.2 or 21.3 which do not have
them.)  The second part of this particular change made the code match
the comment; at the time Gerd said this code dated from at least 1994.

It would be a shame if this change was simply reverted as the particular
problem (multiple unnecessary runs of menu-bar-update-hook on scroll)
will presumably resurface.  Does the fact that you don't always see a
redisplay problem suggest that the bug lies elsewhere?

Richard, at the time you suggested a good general fix was to split the
functionality of windows_or_buffers_changed into different flags for
updating the mode line and updating menus, though I don't think anyone
volunteered to implement it.  Perhaps a flag for updating the tool bar
would also be useful.

Simon.

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

end of thread, other threads:[~2003-03-27 17:40 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-03-23 22:01 Old redisplay bug in xdisp.c, question about change Jan D.
2003-03-24 19:27 ` 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.

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.