bug#76031: 31.0.50; Switching frames on TTY display doesn't work

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.mo>> As I see it, the different meanings of 
>> "visible" are actually just the
>> different effect of being visible in different use-cases.
>>
>> For example, my guess is that the old "if a tty frame is not displayed
>> on the terminal (= "obscured") then consider it visible nonetheless" was
>> just to make use cases like other-frame work.
>
> Maybe so, but other-frame and other similar functions do have to work
> reasonably with TTY frames, right?

I sent a patch for other-frame.

> Also, why aren't you annoyed by the fact that a GUI frame obscured by
> another GUI frame is not considered "invisible"?  Isn't that the same
> situation as with 2 TTY frames on the same display?

If a GUI frame is visible, it must be drawn. If a GUI frame is
invisible, it must not be drawn to.

Details depend on the window system, expose events, possibly the window
manager. Clipping is not Emacs' responsibility. Insofar why would I be
annoyed? It's just how things work.

Before child frames: TTY frames are always visible, invisible doesn't
exist. Visible frames _must_not_ always be drawn, with the known
exception.

After child frames: If a TTY frame is visible, it must be drawn. If a
TTY frame is invisible, it must not be drawn to.

If that's not better, I don't know.

>> I propose something simpler: Make visible = not displayed, and move the
>> different effects on use-cases to the use-cases themselves.
>
> By "the use-cases", do you mean modifications of the Lisp code which
> calls next-frame etc.?  That would mean changes all over the place,
> and not just in Emacs core.  I fear that the 3 functions we found are
> just the tip of a very large iceberg.

I mean use-cases like other-frame, and I'm not afraid :-). If it's Lisp,
it's easy to change.