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

[Hagmonk <hagmonk@icloud.com>]

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