bug#47207: 28.0.50; decode_next_window_args crash

[Eli Zaretskii]

> Cc: 47207@debbugs.gnu.org, acm@muc.de
> From: martin rudalics <rudalics@gmx.at>
> Date: Wed, 17 Mar 2021 16:36:53 +0100
> 
>  >> we probably should decide whether to consider tooltip windows in
>  >> `next-window' or `other-window' at all.
>  >
>  > Not sure why.  Don't we envision some applications that would like to
>  > examine tooltip windows?  IOW, that tooltip frames don't have a
>  > minibuffer doesn't necessarily mean we don't want to give window
>  > iterations access to tooltip windows.
> 
> But then people must be always careful to never look into the minibuffer
> window of a tooltip when writing C code.

But the alternative is IMO much worse: there will be _no_ way
whatsoever to reach those windows via next_window.

The default is already not to consider those windows, so why it is a
problem that they are considered when the code explicitly requests to
consider _all_ the windows?

> Think of minibuf.c's
> 
>        struct frame *sf = XFRAME (selected_frame);
>        /* I don't think that any frames may validly have a null minibuffer
>        window anymore.  */
>        if (NILP (sf->minibuffer_window))
>       emacs_abort ();

That's about the selected-frame, and tooltip frames should never be
selected.  Right?