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

[Keith David Bershatsky]

Thank you, Eli, for looking into this particular thread.

Crosshairs and multiple fake cursors are drawn/erased when the following 
functions are called, each depending upon the flavor of Emacs (NS, X11, W32).  
This approach is based upon the existing method in which the real cursor is 
drawn.

* ns_update_window_end (nsterm.m)

* x_update_window_end (w32term.c)

* x_update_window_end (xterm.c)

Normally, redisplay gets to the above-functions when a window needs updating.  
I want crosshairs and/or fake cursors to be drawn/erased even when there is no 
need to update the window for any other reason.  I throw the boolean switches 
for crosshairs and/or fake cursors a few different ways:  toggle window.h 
switches with a function called from Lisp (sometimes attached to an idle timer, 
sometimes not); or, a keyboard press.  The crosshairs and/or fake cursors also 
erase/draw if they were previously drawn on the window and the cache with their 
prior coordinates is still populated.

When no window updating is required, redisplay_window is *not* called.  The 
most common way for this to happen is an idle timer function being called.  In 
order to make sure that *_update_window_end gets called when redisplay_window 
is *not* involved, I put in a condition preventing redisplay_internal from 
using "goto end_of_redisplay".  In other words, if my boolean switches are 
"true", then do *not* "goto end_of_redisplay".

When loading buffers with a custom desktop restore feature while Emacs is 
starting up, it is possible that this would normally be a "goto 
end_of_redisplay" condition that I have preempted.  However, I would need to do 
more testing to see whether redisplay_window was called on the window where the 
crash occurred.

The conditions of (w != XWINDOW (selected_window)) and (!WINDOW_VALID_P 
(selected_window)) were "wild guesses" on my part in an effort to help avoid 
potential future crashes.

The conditions to see whether eassert would cause a crash in that situation 
(and immediately return if that would be the case) were implemented by me after 
three separate crashes and gdb told me said eassert conditions were the reasons:

(CHARPOS (pos) >= BEGV && CHARPOS (pos) <= ZV);

(charpos == BYTE_TO_CHAR (bytepos));

(BUF_BEG_BYTE (b) <= bytepos && bytepos <= BUF_Z_BYTE (b))

I have commented out the last check, which you indicated was redundant.  I am 
happy to do more work on troubleshooting, which would entail removing the 
conditions that have prevented crashes and then get the backtraces -- perhaps 
that would tell me whether redisplay_window got bypassed such that preemption 
of "goto end_of_redisplay" is the problem.