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

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

[Harald Hanche-Olsen]

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)

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

[Hagmonk]

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

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

[Alan Third]

Hagmonk <hagmonk@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

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

[Lars Ingebrigtsen]

Alan Third <alan@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