[Top][All Lists]

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

Re: Test whether buffer/window is ready for start_display, etc.

From: Eli Zaretskii
Subject: Re: Test whether buffer/window is ready for start_display, etc.
Date: Fri, 29 Sep 2017 19:08:42 +0300

> Date: Wed, 27 Sep 2017 19:21:17 -0700
> From: Keith David Bershatsky <address@hidden>
> In developing implementation of my own feature requests to draw crosshairs 
> (#17684) using multiple fake cursors (#22873), I have come across situations 
> when Emacs is starting up and restoring buffers (custom version of 
> desktop.el) such that several internal functions cause Emacs to crash -- 
> presumably because the combination of buffer and window are not ready yet.  I 
> am presently using the following five (5) tests to see whether window/buffer 
> are ready for things like `start_display`, `move_it_to`, etc.  Is there a 
> better test to see whether the buffer/window combination is ready for me to 
> get to work?

The answer is "always".  The crashes you see must be due to some other
factors, and you haven't told enough to guess what those factors might
be.  Showing a couple of backtraces from those crashes might fill in
those blanks.

>   if (w != XWINDOW (selected_window))
>     return;

This doesn't feel relevant.  You can always redisplay a window that is
not the selected window, provided that you take care to switch to its
buffer (redisplay does that already).

>   if (!WINDOW_VALID_P (selected_window))
>     return;

How did you get into this situation?  It shouldn't happen during
redisplay, AFAIR.

>   ptrdiff_t charpos = marker_position (w->start);
>   ptrdiff_t bytepos = marker_byte_position (w->start);
>   bool barf_crash_one = (charpos >= BEGV && charpos <= ZV) ? false : true;
>   if (barf_crash_one)
>     return;

If window's start point is invalid, it means the window needs to be
redisplayed.  Again, I'm not sure I understand how do you get into
this situation in the middle of redisplay.

>   bool barf_crash_two = (charpos == BYTE_TO_CHAR (bytepos)) ? false : true;
>   if (barf_crash_two)
>     return;

Likewise.  Markers are updated when a buffer is modified, so this
should never happen.

>   bool barf_crash_three = (BUF_BEG_BYTE (b) <= bytepos && bytepos <= 
> BUF_Z_BYTE (b)) ? false : true;
>   if (barf_crash_three)
>     return;

Since you already verified the same condition about the character
position, and you already verified that the character position and the
byte position are consistent, this condition is redundant.

reply via email to

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