Re: Whether a struct window *w is a live/valid window.

[Keith David Bershatsky]

Thank you, Allen, for reading and responding to this particular thread.

I could be wrong, but it appears to me that removal of the vertical scroll bars 
does not remove the glyphs that are underneath.  As such, the glyphs that are 
underneath are not redrawn.  However, removal of the vertical scroll bar has 
the side effect of removing the fake cursors.  My workaround has been to remove 
the scroll bars graciously so as not to cause removal of the fake cursors.  
That way, the fake cursors do not need to be redrawn.  On the NS port, I use 
removeFromSuperviewWithoutNeedingDisplay.  On the w32 port, I use SendMessage 
(hwnd, WM_SETREDRAW, false, 0) before destroying a window (DestroyWindow); and, 
I set the bRepaint argument of MoveWindow to false when the window just needs 
to be moved.

In the current draft of multiple fake cursors, they are laid immediately 
following the calls to draw_glyphs.

FACT PATTERNS:  Two (2) adjacent windows (left/right) within a single frame.  
Either the user deletes the left window; or, the user deletes the right window. 
 When the user deletes the left window, its scroll bar (center of screen) is no 
longer associated with a live/valid window.  When a user deletes the right 
window, the scroll bar (center of screen) remains associated with the left 
window but needs to be moved.

When either the left or right window is deleted, update_window redraws all of 
the screen lines and effectively erases the scroll bar (center of screen).  In 
a related thread, Eli Z. was kind enough to provide an outline of the relevant 
events:

  . `redisplay_internal' calls the `condemn_scroll_bars_hook', which marks all 
scroll bars as candidates for deletion.

  . Then `redisplay_internal' calls `redisplay_windows', which walks the 
window-tree and examines each window, whereby each window that is still alive 
in the window-tree "redeems" its scroll bars by marking them not to be deleted.

  . Then `redisplay_internal' calls `judge_scroll_bars_hook', which removes all 
the scroll bars that were not "redeemed".

  . And only after that `redisplay_internal' calls `update_frame', which calls 
`update_window' for each live window, and that ends up calling `draw_glyphs' to 
deliver the updated contents to the glass.

When I stepped through the code, I observed that removal of the scroll bars is 
delayed on the NS and W32 platforms.  update_window runs _before_ scroll bars 
are actually removed.  Scroll bar removal occurs during read_char at 
approximately the location of read_decoded_event_from_main_queue.

http://www.lawlist.com/images/after_03_10_2019.png

The w32 port uses a Lisp_Object for the WINDOW component of the scroll bar 
structure.  Calling WINDOW_LIVE_P seems to be working well on that platform.

The NS port uses `struct window *window`, and Emacs occasionally crashes when I 
have attempted to use XSETWINDOW (as described in the initial post of this 
thread).  My workaround is to tentatively use:

   if (w != NULL
       && NILP (w->contents))

instead of trying to create a Lisp_Object with XSETWINDOW so that I can then 
use WINDOW_LIVE_P.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

> Date: [03-22-2019 08:01:48] <22 Mar 2019 15:01:48 +0000>
> From: Alan Third <address@hidden>
> To: Keith David Bershatsky <address@hidden>
> Cc: Emacs Devel <address@hidden>
> Subject: Re: Whether a struct window *w is a live/valid window.
> 
> On Wed, Mar 20, 2019 at 01:14:13PM -0700, Keith David Bershatsky wrote:
> > I am working on feature requests #22873 (multiple fake cursors) and
> > crosshairs #17684 (crosshairs that track the cursor position).
> >
> > In trying to resolve an issue where removal of vertical scroll bars
> > erased fake cursors that were laid during update_window
> 
> Sorry if this has already been covered, but after the scrollbar is
> removed the toolkit should mark the area under the toolkit as needing
> redrawn. That will then cause [EmacsView drawRect:], and subsequently
> expose_frame, to be called on that rectangle. Why aren't the cursors
> being redrawn at that time?
> 
> Is everything else ‘under' the scrollbars being drawn correctly?
> --
> Alan Third