bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Wed, 05 Feb 2025 17:27:40 +0200

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: rudalics@gmx.at,  76031@debbugs.gnu.org
> Date: Wed, 05 Feb 2025 16:05:26 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I don't find that a good idea because
> >
> > Not even in principle, i.e. to have two flags instead of one?  The
> > details of the flags could be different from what I proposed.
> 
> Not even in principle, no. I don't see ATM how that would be useful.

It could be useful if it will solve the problems with next-frame and
other-frame without requiring modifications of Lisp code that is too
high-level.

We could also keep using a single flag, just call it by a different
name, so that it won't confuse due to the fact that "not visible"
could be caused either by not displaying a frame or by its being
obscured.  next-frame and friends care about the former, but not about
the latter.

> > Do you disagree that we have several different meanings of "invisible
> > frame", and that it would be better not to conflate them into a single
> > boolean?
> 
> 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?

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?

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]