bug#47207: 28.0.50; decode_next_window_args crash

[martin rudalics]

>>   >> How would we handle that suggestion in say `next-window-any-frame'?
>>   >
>>   > Skip tooltip frames, I guess.
>>
>> But how if we don't want to do it in `next-frame'?
>
> 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.  The idea is simple ...

(defun next-window-any-frame ()
  "Select the next window, regardless of which frame it is on."
  (interactive)
  (catch 'failed
    (let ((selected (selected-window))
          (next (next-window nil nil 0)))
      (while (window-tooltip-p next)
        (setq next (next-window next nil 0))
        (when (eq next selected)
          (throw 'failed nil)))

      (select-window next)
      (select-frame-set-input-focus (selected-frame)))))

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

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

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

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

martin