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

[Keith David Bershatsky <esq@lawlist.com>]

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.