GNU bug report logs - #5985
23.1.96; Mac OS X: Frames in other spaces erroneously thought visible

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 5985 in the body.
You can then email your comments to 5985 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Harald Hanche-Olsen <hanche <at> math.ntnu.no>
To: bug-gnu-emacs <at> gnu.org
Subject: 23.1.96; Mac OS X: Frames in other spaces erroneously thought visible
Date: Tue, 20 Apr 2010 09:52:50 -0400 (EDT)

On OS X, enable Spaces. (Note to those who don't use Macs: Spaces are
a bit like virtual desktops in many X11 window managers.) Run emacs
and create two or more frames. Move some frames to different spaces.

Evaluate (visible-frame-list).

Expected result: Only frames in the current space should be listed.
Actual result: All non-iconified frames are listed.

As a side effect, C-x 5 o (other-frame) can select a frame in a
different space. Also, (frame-visible-p) evaluated in a frame in a
different space will return t.


In GNU Emacs 23.1.96.1 (i386-apple-darwin9.8.0, NS apple-appkit-949.54)
 of 2010-04-20 on mach
Windowing system distributor `Apple', version 10.3.949
configured using `configure  '--with-ns''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  value of $XMODIFIERS: nil
  locale-coding-system: nil
  default enable-multibyte-characters: t

Major mode: Emacs-Lisp

Minor modes in effect:
  paredit-mode: t
  show-paren-mode: t
  delete-selection-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<return> C-x 5 b * s c <tab> <return> ( <backspace> 
M-x p a r e - m o <tab> <return> ( l i s t - v i s 
<tab> <escape> <tab> M-b <M-backspace> C-f C-f C-f 
i b <escape> <tab> f r a m <tab> <escape> <tab> <return> 
<backspace> C-e C-x C-e <switch-frame> <switch-frame> 
M-x b u g <tab> <escape> <backspace> <escape> <backspace> 
r e p o <tab> r <tab> <return>

Recent messages:
Making a message...done
+draft/3 has been queued to +queue/1 (from Draft mode)
Creating an SSL/TLS connection...done
Connecting to the SMTP server...done
Sending in background...done
Paredit mode enabled
No match
(#<frame mach:%list.emacs-devel 0x5e1510> #<frame mach:*scratch* 0x1801f310>)
Making completion list...
Type C-x 1 to delete the help window.

Load-path shadows:
/Users/hanche/lib/lisp/slime/hyperspec hides /Users/hanche/lib/emacs/hyperspec
/Users/hanche/lib/emacs/md4 hides /Applications/Emacs.app/Contents/Resources/lisp/md4
/Users/hanche/lib/emacs/cl-indent hides /Applications/Emacs.app/Contents/Resources/lisp/emacs-lisp/cl-indent

Features:
(shadow emacsbug vc-dispatcher vc-rcs sgml-mode help-mode view
mew-varsx mew-auth mew-config mew-imap2 mew-imap mew-nntp2 mew-nntp
mew-pop mew-smtp mew-ssl mew-ssh mew-net mew-highlight mew-sort
mew-fib mew-ext mew-refile mew-demo mew-attach mew-draft mew-message
mew-thread mew-virtual mew-summary4 mew-summary3 mew-summary2
mew-summary mew-search mew-pick mew-passwd mew-scan mew-syntax mew-bq
mew-smime mew-pgp mew-header mew-exec mew-mark mew-mime mew-edit
mew-decode mew-encode mew-cache mew-minibuf mew-complete mew-addrbook
mew-local mew-darwin mew-vars3 mew-vars2 mew-vars mew-env mew-mule3
mew-mule mew-gemacs mew-key mew-func mew-blvs mew-const mew
multi-isearch compile paredit eldoc slime-asdf slime-fancy
slime-fontifying-fu slime-package-fu slime-references
slime-xref-browser tree-widget wid-edit slime-scratch
slime-presentations slime-highlight-edits slime-fuzzy
slime-fancy-inspector slime-c-p-c slime-editing-commands slime-autodoc
slime-parse slime-repl slime byte-opt bytecomp byte-compile regexp-opt
derived apropos edmacro kmacro hideshow pp comint ring hyperspec
browse-url named-strings indentation gnus-custom advice help-fns
advice-preload slime-autoloads parenface paren delsel server
odds-and-ends thingatpt easy-mmode cl cl-19 tooltip ediff-hook
vc-hooks lisp-float-type mwheel ns-win easymenu tool-bar dnd fontset
image fringe lisp-mode register page menu-bar rfn-eshadow timer select
scroll-bar mldrag mouse jit-lock font-lock syntax facemenu font-core
frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev loaddefs button minibuffer faces
cus-face files text-properties overlay md5 base64 format env
code-pages mule custom widget hashtable-print-readable backquote
make-network-process dbusbind ns multi-tty emacs)

Message #8 received at 5985 <at> debbugs.gnu.org (full text, mbox):

From: Hagmonk <hagmonk <at> icloud.com>
To: 5985 <at> debbugs.gnu.org
Subject: Re: bug#5985: 23.1.96; Mac OS X: Frames in other spaces erroneously
 thought visible
Date: Sat, 05 Mar 2016 20:52:53 -0800

> On OS X, enable Spaces. (Note to those who don't use Macs: Spaces are
> a bit like virtual desktops in many X11 window managers.) Run emacs
> and create two or more frames. Move some frames to different spaces.
> 
> Evaluate (visible-frame-list).
> 
> Expected result: Only frames in the current space should be listed.
> Actual result: All non-iconified frames are listed.
> 
> As a side effect, C-x 5 o (other-frame) can select a frame in a
> different space. Also, (frame-visible-p) evaluated in a frame in a
> different space will return t.

It’s not clear to me what the desired behavior should be here. From the documentation:

---
(frame-visible-p FRAME)

Return t if FRAME is "visible" (actually in use for display).
Return the symbol ‘icon’ if FRAME is iconified or "minimized".
Return nil if FRAME was made invisible, via ‘make-frame-invisible’.
On graphical displays, invisible frames are not updated and are
usually not displayed at all, even in a window system’s "taskbar".
---

Minimizing a window does result in the symbol “icon” being returned. However, OS X doesn’t have the notion of making an individual window invisible. Command-H will hide all windows for an application. And although there is no “taskbar” if you invoke mission control to see available windows, the window remains “displayed" in that sense. In fact while mission control is active, the app’s thumbnail is a live representation of the app’s window state (try playing a movie and then invoke mission control from another space)

It seems if OS X had the notion of hiding an individual window, frame visibility could be keyed off that window state. Without that, it’s not clear how this would be supported without changing the definition of visibility used by frame-visible-p.

I’m inclined to suggest this behaves as intended. 

Message #11 received at 5985 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Hagmonk <hagmonk <at> icloud.com>
Cc: 5985 <at> debbugs.gnu.org
Subject: Re: bug#5985: 23.1.96;
 Mac OS X: Frames in other spaces erroneously thought visible
Date: Tue, 17 May 2016 20:05:20 +0100

Hagmonk <hagmonk <at> icloud.com> writes:

>> On OS X, enable Spaces. (Note to those who don't use Macs: Spaces are
>> a bit like virtual desktops in many X11 window managers.) Run emacs
>> and create two or more frames. Move some frames to different spaces.
>> 
>> Evaluate (visible-frame-list).
>> 
>> Expected result: Only frames in the current space should be listed.
>> Actual result: All non-iconified frames are listed.
>> 
>> As a side effect, C-x 5 o (other-frame) can select a frame in a
>> different space. Also, (frame-visible-p) evaluated in a frame in a
>> different space will return t.
>
> It’s not clear to me what the desired behavior should be here. From the documentation:
>
> ---
> (frame-visible-p FRAME)
>
> Return t if FRAME is "visible" (actually in use for display).
> Return the symbol ‘icon’ if FRAME is iconified or "minimized".
> Return nil if FRAME was made invisible, via ‘make-frame-invisible’.
> On graphical displays, invisible frames are not updated and are
> usually not displayed at all, even in a window system’s "taskbar".
> ---
>
> Minimizing a window does result in the symbol “icon” being returned.
> However, OS X doesn’t have the notion of making an individual window
> invisible. Command-H will hide all windows for an application. And
> although there is no “taskbar” if you invoke mission control to see
> available windows, the window remains “displayed" in that sense. In
> fact while mission control is active, the app’s thumbnail is a live
> representation of the app’s window state (try playing a movie and then
> invoke mission control from another space)
>
> It seems if OS X had the notion of hiding an individual window, frame
> visibility could be keyed off that window state. Without that, it’s
> not clear how this would be supported without changing the definition
> of visibility used by frame-visible-p.
>
> I’m inclined to suggest this behaves as intended. 

And I'm inclined to agree. However, if someone with access to an X
system with virtual desktops (or similar) could test how it behaves,
that would be helpful in determining exactly what the correct behaviour
should be.

Unless someone happens to just know?

-- 
Alan Third

Message #14 received at 5985 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Alan Third <alan <at> idiocy.org>
Cc: Hagmonk <hagmonk <at> icloud.com>, 5985 <at> debbugs.gnu.org
Subject: Re: bug#5985: 23.1.96; Mac OS X: Frames in other spaces erroneously
 thought visible
Date: Sun, 18 Jul 2021 15:32:55 +0200

Alan Third <alan <at> idiocy.org> writes:

> And I'm inclined to agree. However, if someone with access to an X
> system with virtual desktops (or similar) could test how it behaves,
> that would be helpful in determining exactly what the correct behaviour
> should be.

I tried this now (on Debian/bullseye + Gnome Shell), and
`frame-visible-p' behaves as on Macos -- even if the frame in question
is on another virtual desktop, it returns t.

So this seems to behave consistently across systems, and I'm closing
this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.