bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#13007: 24.3.50; emacs_backtrace.txt


From: Eli Zaretskii
Subject: bug#13007: 24.3.50; emacs_backtrace.txt
Date: Fri, 30 Nov 2012 18:59:47 +0200

> Date: Fri, 30 Nov 2012 19:50:57 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> CC: 13007@debbugs.gnu.org, lekktu@gmail.com, drew.adams@oracle.com
> 
> 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.

I don't see that.  That function checks if the buffer is the same as
the one recorded in window's matrix.

> 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)?

I don't think you can do that, since sometimes a non-selected window
needs to be redisplayed.

> 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.

Are the menu-bar and tool-bar "windows" non-leaf?

>  static void
>  reconsider_clip_changes (struct window *w, struct buffer *b)
>  {
> +  eassert (XBUFFER (w->buffer) == b);
> +

How is this different from this:

>    if (b->clip_changed
>          && !NILP (w->window_end_valid)
>          && w->current_matrix->buffer == b
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> +  if (XBUFFER (w->buffer) != current_buffer)
> +    /* Out of sync, do nothing.  */
> +    goto end_of_redisplay;

I'm nervous about this, to tell the truth.  redisplay_internal never
dependent on current_buffer.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]