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

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

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 <alan@idiocy.org>
> To: Keith David Bershatsky <esq@lawlist.com>
> Cc: Emacs Devel <emacs-devel@gnu.org>
> 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