all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Dmitry Antipov <dmantipov@yandex.ru>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 13007@debbugs.gnu.org, lekktu@gmail.com
Subject: bug#13007: 24.3.50; emacs_backtrace.txt
Date: Fri, 30 Nov 2012 19:50:57 +0400	[thread overview]
Message-ID: <50B8D5E1.7090005@yandex.ru> (raw)
In-Reply-To: <83a9tzv2m0.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 1407 bytes --]

On 11/30/2012 01:53 PM, Eli Zaretskii wrote:

> OK.  So what do you suggest, in practical terms?  Are you saying that
> we should use BUF_MODIFF(XBUFFER (w->buffer)) instead of MODIFF and
> BUF_OVERLAY_MODIFF(XBUFFER (w->buffer)) instead of OVERLAY_MODIFF
> inside window_outdated?  Or do you suggest something else?
>
> I'm okay with using BUF_* macros in window_outdated.

There is one more similar thing: if we can enter redisplay_internal
with different current_buffer and selected window's buffer, we can
confuse reconsider_clip_changes, which comment explicitly assumes
that W->buffer and B are the same buffer.

What if we just delay the real redisplay action until current_buffer
and selected window's buffer becomes synchronized, assuming that it
happens in the very near future (when someone finally update current_buffer
with selected window's buffer and then attract redisplay attention with
++windows_or_buffers_changed or similar)?

> So if window_outdated is called not from redisplay_window or its
> subroutines, we cannot assume that current_buffer and the selected
> window's buffer are the same.  Also, for minibuffer windows and
> pseudo-windows, we may need more care, but I'm not sure.

IIUC pseudo-windows are always non-leaf; so, selected_window can't be
a pseudo-window, and pseudo-window can't be passed to redisplay_window.

Attached patch illustrates all from the above.

Dmitry

[-- Attachment #2: 3.patch --]
[-- Type: text/plain, Size: 2152 bytes --]

=== modified file 'src/xdisp.c'
--- src/xdisp.c	2012-11-30 09:23:15 +0000
+++ src/xdisp.c	2012-11-30 15:45:36 +0000
@@ -10906,6 +10906,7 @@
 static int
 window_outdated (struct window *w)
 {
+  eassert (XBUFFER (w->buffer) == current_buffer);
   return (w->last_modified < MODIFF 
 	  || w->last_overlay_modified < OVERLAY_MODIFF);
 }
@@ -12917,6 +12918,8 @@
 static void
 reconsider_clip_changes (struct window *w, struct buffer *b)
 {
+  eassert (XBUFFER (w->buffer) == b);
+
   if (b->clip_changed
 	   && !NILP (w->window_end_valid)
 	   && w->current_matrix->buffer == b
@@ -12924,13 +12927,11 @@
 	   && w->current_matrix->begv == BUF_BEGV (b))
     b->clip_changed = 0;
 
-  /* If display wasn't paused, and W is not a tool bar window, see if
-     point has been moved into or out of a composition.  In that case,
-     we set b->clip_changed to 1 to force updating the screen.  If
-     b->clip_changed has already been set to 1, we can skip this
-     check.  */
-  if (!b->clip_changed
-      && BUFFERP (w->buffer) && !NILP (w->window_end_valid))
+  /* If display wasn't paused, see if point has been moved into or
+     out of a composition.  In that case, we set b->clip_changed
+     to 1 to force updating the screen.  If b->clip_changed has
+     already been set to 1, we can skip this check.  */
+  if (!b->clip_changed && !NILP (w->window_end_valid))
     {
       ptrdiff_t pt;
 
@@ -13079,6 +13080,10 @@
      may need to run Elisp code (via prepare_menu_bars).  */
   ensure_selected_frame (old_frame);
 
+  if (XBUFFER (w->buffer) != current_buffer)
+    /* Out of sync, do nothing.  */
+    goto end_of_redisplay;
+
   pending = 0;
   reconsider_clip_changes (w, current_buffer);
   last_escape_glyph_frame = NULL;
@@ -13136,10 +13141,7 @@
   /* do_pending_window_change could change the selected_window due to
      frame resizing which makes the selected window too small.  */
   if (WINDOWP (selected_window) && (w = XWINDOW (selected_window)) != sw)
-    {
-      sw = w;
-      reconsider_clip_changes (w, current_buffer);
-    }
+    goto retry;
 
   /* Clear frames marked as garbaged.  */
   clear_garbaged_frames ();


  reply	other threads:[~2012-11-30 15:50 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-27  6:23 bug#13007: 24.3.50; emacs_backtrace.txt Drew Adams
2012-11-27  6:28 ` Drew Adams
2012-11-27 15:15   ` Eli Zaretskii
2012-11-27 15:41     ` Drew Adams
2012-11-27 15:44       ` Drew Adams
2012-11-27 16:39     ` Juanma Barranquero
2012-11-27 18:02       ` Eli Zaretskii
2012-11-27 15:14 ` Eli Zaretskii
2012-11-27 16:49   ` Dmitry Antipov
2012-11-27 17:47     ` Eli Zaretskii
2012-11-27 17:58       ` Jambunathan K
2012-11-27 18:10         ` Drew Adams
2012-11-28  7:19       ` Dmitry Antipov
2012-11-28 13:09         ` Juanma Barranquero
2012-11-28 15:51           ` Dmitry Antipov
2012-11-28 17:59             ` Eli Zaretskii
2012-11-29  6:19               ` Dmitry Antipov
2012-11-29 16:46                 ` Eli Zaretskii
2012-11-29 17:02                   ` Drew Adams
2012-11-29 17:39                     ` Eli Zaretskii
2012-11-29 17:47                       ` Drew Adams
2012-11-29 18:08                         ` Eli Zaretskii
2012-11-29 18:13                           ` Drew Adams
2012-11-29 19:50                             ` Eli Zaretskii
2012-11-29 17:23                   ` Dmitry Antipov
2012-11-30  9:53                     ` Eli Zaretskii
2012-11-30 15:50                       ` Dmitry Antipov [this message]
2012-11-30 16:59                         ` Eli Zaretskii
2015-12-29 11:08                       ` Lars Ingebrigtsen
2015-12-29 17:37                         ` Eli Zaretskii
2016-01-02 11:10                           ` Eli Zaretskii
2012-11-29 19:14                   ` Stefan Monnier
2012-11-29 19:54                     ` Eli Zaretskii

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=50B8D5E1.7090005@yandex.ru \
    --to=dmantipov@yandex.ru \
    --cc=13007@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=lekktu@gmail.com \
    /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.