bug#47207: 28.0.50; decode_next_window_args crash

[martin rudalics]

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

What would you do instead?

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

I don't know what TSA is and its relevance to Emacs.  But when Basil
proposed to add a function called `marker-list' you answered

  Just reading the markers probably won't but do you really believe this
  is the last word?  How many hours will it take for someone to ask for
  a primitive to set the C-level markers as well, or request the ability
  to map a function over all the markers?  If it's really needed, sure,
  let's do it.  But is it?  Or are we doing that just because we can?

which ended up with Bug#35536 marked as wontifx.  For me this is a
classic example of "punishing the innocent for fear of the evil".

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

Because in my crash scenario (other-window 1 t) selects the tooltip
window.

martin