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: Thu, 18 Mar 2021 09:43:57 +0100
> 
>  > I don't think I understand what's bothering you.  The idea is simple:
>  > if you get a frame that's a tooltip frame, ask for another one.
> 
> Like the below, I suppose.

Something like that, yes.

> ... but we don't even have `window-tooltip-p' yet.

It's a one-liner, isn't it?  I'm not even sure we need a function for
that, but I won't object adding one.

>  >> Checking whether the returned frame is a tooltip frame in
>  >> `next-window-any-frame' means any Lisp code that does not do
>  >> something similar can crash Emacs.
>  >
>  > Crash how?
> 
> As in my report.  These were the only times I've been losing Emacs
> sessions in the past years.

If we didn't fix that yet, let's fix it ASAP.

>  > In any case, the idea that something applications might forget to do
>  > would mean we must push the checks to lower levels sounds wrong to me.
>  > Lower levels should be free from application-level constraints, so
>  > that if someone wants to write code which breaks those constraints,
>  > he/she could do that.
> 
> Why did you decline the proposal to expose buffer markers to Elisp?

How is that relevant to the present discussion?

>  > That those who do it must know what they are
>  > doing is a truism; restricting legitimate uses for fear of
>  > illegitimate ones is punishing the innocent for fear of the evil --
>  > that's the problem with TSA, for example.
> 
> We still have no concept for whether and where we would refuse
> selecting a tooltip window - in `select-window', select_window,
> `select-frame', wherever we set selected_window ...

Then let's develop that concept.  But again, how is this relevant to
the issue at hand?