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

[Alan Third]

On Fri, Mar 22, 2019 at 11:30:26PM -0700, Keith David Bershatsky wrote:
> 
> 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.

OK, I think you have a slight misunderstanding of what ‘removing the
scrollbars’ does, on NS at lease.

When a scrollbar is removed it doesn’t ‘undraw’ the scrollbar from the
screen, it marks the area it was as needing to be redrawn, and that is
done from scratch. So the fact that the glyphs don’t appear to be
deleted means that they are *redrawn*. The multiple cursors appear to
be deleted, so that means that they are *not* redrawn.

The redrawing doesn’t happen synchronously either. It occurs when we
call [NSApp run], which is generally done when we’re handling input.

If you look in nsterm.m you’ll see a call in ns_read_socket and
ns_select. That’s where the screen will be redrawn.

You could try redrawing the cursors in [EmacsView drawRect:], but it
has no concept of Emacs windows, so you would have to step through
them and make sure you only updated the windows in the current frame,
and that they’re live.

It would be better if they were redrawn in expose_window, perhaps.

One thing to bear in mind is that drawRect: sets up clipping areas so
you can’t draw outside areas that have been marked for update. So the
usual drawing routine goes like

redisplay:
  mark area as dirty (setNeedsDisplayInRect:)
  
check for input:
  run the NS event loop ([NSApp run])
    drawRect:
      expose_frame
        expose_window
          do actual drawing somewhere in here

> 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))

That looks reasonable to me.
-- 
Alan Third