Frame ordering

Frame ordering

[David Reitter]

Currently, frames seem to be selected in order of their creation; deleting a frame does not select the previously created frame, but the frame that was created before it.  Many users (e.g., see below) find this annoying, and so do I.

So, I've experimented with simply moving the frame to the end of Vframe_list in do_switch_frame:

if (XINT (Flength (Vframe_list)) > 1)
    {
      Vframe_list = Fdelete (frame, Vframe_list);
      Vframe_list = nconc2 (Vframe_list, tem);
    }

However, this results in hangs in redisplay or in outright crashes, depending on the variant of the above (sometimes in garbage collection).  What am I doing wrong?




Begin forwarded message:

> From: Konrad Podczeck <konrad.podczeck@univie.ac.at>
> 
> I start Aquamacs, then, via "Open Recent", I open a file, say one.tex, and then another file, say second.tex. Then, via "Menu>Window", I make the frame with one.tex again the active one. Then I invoke "occur" to get a new frame containing an occur buffer. Now if I close the occur buffer, suddenly the frame with second.tex becomes active, which is not the frame from which I called "occur". Similar effects with latex output buffers.

Re: Frame ordering

[martin rudalics]

 > So, I've experimented with simply moving the frame to the end of Vframe_list in do_switch_frame:

Why do you want to do this in do_switch_frame?

 >
 > if (XINT (Flength (Vframe_list)) > 1)
 >     {
 >       Vframe_list = Fdelete (frame, Vframe_list);
 >       Vframe_list = nconc2 (Vframe_list, tem);
 >     }

What is tem and what is its cdr?

martin

Re: Frame ordering

[David Reitter]

On Jun 11, 2010, at 9:22 AM, martin rudalics wrote:

> > So, I've experimented with simply moving the frame to the end of Vframe_list in do_switch_frame:
> 
> Why do you want to do this in do_switch_frame?

I thought that would be a good place where to record the selection of a different frame.
(Of course, one should restrict it to cases where users select the frame (or create one), rather than temporary selection of the frame through a program.)

> >       Vframe_list = nconc2 (Vframe_list, tem);
> 
> What is tem and what is its cdr?

Ah sorry, I forgot to show this.  Here's what I meant.

  if (XINT (Flength (Vframe_list)) > 1)
    {
      Vframe_list = Fdelete (frame, Vframe_list);
      Vframe_list = nconc2 (Vframe_list, Fcons (frame, Qnil));
    }

and something equivalent like Fnreverse (Fcons (frame, Fnreverse (Vframe_list)))  does the same and I'd like to understand why.

Re: Frame ordering

[martin rudalics]

 >> Why do you want to do this in do_switch_frame?
 >
 > I thought that would be a good place where to record the selection of a different frame.

I'd write a simple function to reorder frames, make it callable from
Lisp, and test it from there first.

 > Ah sorry, I forgot to show this.  Here's what I meant.
 >
 >   if (XINT (Flength (Vframe_list)) > 1)
 >     {
 >       Vframe_list = Fdelete (frame, Vframe_list);

I'd use Fdelq here.

 >       Vframe_list = nconc2 (Vframe_list, Fcons (frame, Qnil));
 >     }
 >
 > and something equivalent like Fnreverse (Fcons (frame, Fnreverse (Vframe_list)))  does the same and I'd like to understand why.

martin

Re: Frame ordering

[David Reitter]

On Jun 11, 2010, at 1:13 PM, martin rudalics wrote:
> 
> I'd write a simple function to reorder frames, make it callable from
> Lisp, and test it from there first.

OK, that works. 
What next?
`handle-switch-frame' could be defined in Lisp anyway, calling the current Fhandle_switch_frame primitive.

That said, why did the same not work in do_switch_frame, and why did my other variant (that I posted) lead to hangs and crashes?



(global-set-key [switch-frame] 'my-handle-switch-frame)

(defun my-handle-switch-frame ( event)
  (interactive "e")
  (handle-switch-frame event)
  (set-latest-frame (selected-frame)))
  

DEFUN ("set-latest-frame", Fset_latest_frame, Sset_latest_frame, 1, 1, 0,
       doc: /* Make FRAME the last frame in the frame list. */)
     (frame)
     Lisp_Object frame;
{
  if (NILP (frame))
    frame = selected_frame;
  if (!FRAMEP (frame))
    return Qnil;
  Vframe_list = Fcons (frame, Fdelq (frame, Vframe_list));
  return Qnil;  /* don't return the new frame-list - see Fframe_list */
}

Re: Frame ordering

[martin rudalics]

 >> I'd write a simple function to reorder frames, make it callable from
 >> Lisp, and test it from there first.
 >
 > OK, that works.
 > What next?
 > `handle-switch-frame' could be defined in Lisp anyway, calling the current Fhandle_switch_frame primitive.

I don't think so.  IIUC it's purpose is to hide do_switch_frame from
Elisp.

 > That said, why did the same not work in do_switch_frame, and why did my other variant (that I posted) lead to hangs and crashes?
[...]
 > (defun my-handle-switch-frame ( event)
 >   (interactive "e")
 >   (handle-switch-frame event)
 >   (set-latest-frame (selected-frame)))

I can only guess.  do_switch_frame handles an event and when the frame
list is in the state of restructuring and an event occurs, you might end
up with a broken frame list (or a broken window or buffer list given the
fact that do_switch_frame calls `select-window').

In addition, as I recently noticed in the buffer list handling routines,
frame/window/buffer lists are frequently updated via Fdelq and that
function can quit.  I suppose that in all these cases we'd have to use
delq_no_quit (and similar functions) instead to be on the safe side.

Your `my-handle-switch-frame' seems safe because you serialized
`set-latest-frame' with do_switch_frame - so you won't suffer any of the
problems above.  If, however, you were able to interrupt a call to
`set-latest-frame' somehow (maybe by running it in an infinite loop),
you might be able to produce a crash too.

martin

Re: Frame ordering

[David Reitter]

On Jun 12, 2010, at 4:01 AM, martin rudalics wrote:


> > `handle-switch-frame' could be defined in Lisp anyway, calling the current Fhandle_switch_frame primitive.
> 
> I don't think so.  IIUC it's purpose is to hide do_switch_frame from
> Elisp.

Either way, it might not be the right solution.
When selecting a frame from the Buffer menu, the switch-frame event doesn't seem to be generated.
Of course, this could be fixed manually, but what happens when `select-frame' is used (e.g., M-x other-frame)?

At the same time, we definitely want to avoid reordering due to temporary selection of a frame in code (e.g., `with-selected-frame').

Should Vframe_list not be updated in the event loop?

Re: Frame ordering

[Stefan Monnier]

> Should Vframe_list not be updated in the event loop?

Why not update it in Fselect_frame, and obey the `norecord' argument?


        Stefan

Re: Frame ordering

[David Reitter]

On Jun 13, 2010, at 8:30 PM, Stefan Monnier wrote:

>> Should Vframe_list not be updated in the event loop?
> 
> Why not update it in Fselect_frame, and obey the `norecord' argument?


Tried that - doesn't catch clicks into the frame by the user.

However, I got the code below to work at the end of do_switch_frame.   

I think this would be a substantial, and good change to the way frames are ordered.  Are you OK with this?




*** ../../em24.git/src/frame.c	2010-04-30 18:30:17.000000000 -0400
--- frame.c	2010-06-13 22:33:19.000000000 -0400
***************
*** 881,886 ****
--- 881,893 ----
       the one you're actually typing in.  */
    internal_last_event_frame = Qnil;
  
+   if (NILP (norecord))
+     {
+       BLOCK_INPUT;
+       Vframe_list = Fcons (frame, Fdelq (frame, Vframe_list));
+       UNBLOCK_INPUT;
+     }
+ 
    return frame;
  }
  

Re: Frame ordering

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 13 Jun 2010 22:42:40 -0400, David Reitter <david.reitter@gmail.com> said:

> On Jun 13, 2010, at 8:30 PM, Stefan Monnier wrote:
>>> Should Vframe_list not be updated in the event loop?
>> 
>> Why not update it in Fselect_frame, and obey the `norecord'
>> argument?

> Tried that - doesn't catch clicks into the frame by the user.

> However, I got the code below to work at the end of do_switch_frame.

> I think this would be a substantial, and good change to the way
> frames are ordered.  Are you OK with this?

Did you confirm that the original problem was not specific to the NS
port?

We usually don't need to specify the next focus window (in
window-system terminology) that is to be selected when a window is
closed.  The window system or the window manager automatically move
the focus according to its policy (e.g., the frontmost window, which
may belong to another application).  This also applies to Cocoa
AppKit.

http://lists.gnu.org/archive/html/bug-gnu-emacs/2009-05/msg00373.html
http://lists.gnu.org/archive/html/bug-gnu-emacs/2009-05/msg00413.html

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Frame ordering

[martin rudalics]

 > We usually don't need to specify the next focus window (in
 > window-system terminology) that is to be selected when a window is
 > closed.  The window system or the window manager automatically move
 > the focus according to its policy (e.g., the frontmost window, which
 > may belong to another application).  This also applies to Cocoa
 > AppKit.

IIUC David only talks about the foremost _Emacs_ "window" that shall get
attention here.  So _if_ we want to specify which other frame shall be
shown when a frame gets deleted, we also should be able to communicate
that to the window managers in some way.

martin

Re: Frame ordering

[Lennart Borgman]

On Mon, Jun 14, 2010 at 8:50 AM, martin rudalics <rudalics@gmx.at> wrote:
>
> attention here.  So _if_ we want to specify which other frame shall be
> shown when a frame gets deleted, we also should be able to communicate
> that to the window managers in some way.

Is not that possible by first raising the new frame and then deleting
the frame that should be deleted?

However we must then have a way to know when the new frame have been
raised and is foremost. Do we have that?

Re: Frame ordering

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 14 Jun 2010 08:50:56 +0200, martin rudalics <rudalics@gmx.at> said:

>> We usually don't need to specify the next focus window (in
>> window-system terminology) that is to be selected when a window is
>> closed.  The window system or the window manager automatically move
>> the focus according to its policy (e.g., the frontmost window,
>> which may belong to another application).  This also applies to
>> Cocoa AppKit.

> IIUC David only talks about the foremost _Emacs_ "window" that shall
> get attention here.

At least Cocoa AppKit selects the foremost one just as we expect,
without the necessity of specifying the window that shall be shown.
That's the behavior of Emacs 22 Carbon+AppKit port and Emacs 23 Mac
port.  As far as I tested, many X11 window managers also behave like
this.  Only the NS port doesn't for some reason.

Given such situations, I'd think we should avoid touching the
platform-independent part (unless we have such a rather unusual
requirement like below).

> So _if_ we want to specify which other frame shall be shown when a
> frame gets deleted, we also should be able to communicate that to
> the window managers in some way.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Frame ordering

[martin rudalics]

 > At least Cocoa AppKit selects the foremost one just as we expect,
 > without the necessity of specifying the window that shall be shown.
 > That's the behavior of Emacs 22 Carbon+AppKit port and Emacs 23 Mac
 > port.  As far as I tested, many X11 window managers also behave like
 > this.  Only the NS port doesn't for some reason.

It would be interesting to know whether the NS port "buries" the
foremost Emacs window at the time it selects another one (or creates a
new one).  That is, if you have at least four Emacs frames and delete
them one by one, how does the other frame shown relate to the order in
which frames were created or changed their position in the Z-order.

Also, in delete_frame we have to select another frame in case the deleted
frame is the selected one.  Next comes:

#ifdef NS_IMPL_COCOA
       else
	/* Under NS, there is no system mechanism for choosing a new
	   window to get focus -- it is left to application code.
	   So the portion of THIS application interfacing with NS
	   needs to know about it.  We call Fraise_frame, but the
	   purpose is really to transfer focus.  */
	Fraise_frame (frame1);
#endif

before we do switch frames.  Is this related to the issue at hand?

martin

Re: Frame ordering

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 14 Jun 2010 10:24:24 +0200, martin rudalics <rudalics@gmx.at> said:

> Also, in delete_frame we have to select another frame in case the deleted
> frame is the selected one.  Next comes:

> #ifdef NS_IMPL_COCOA
>        else
> 	/* Under NS, there is no system mechanism for choosing a new
> 	   window to get focus -- it is left to application code.
> 	   So the portion of THIS application interfacing with NS
> 	   needs to know about it.  We call Fraise_frame, but the
> 	   purpose is really to transfer focus.  */
> 	Fraise_frame (frame1);
> #endif

> before we do switch frames.  Is this related to the issue at hand?

I think so.  That's why I referred to

http://lists.gnu.org/archive/html/bug-gnu-emacs/2009-05/msg00373.html
http://lists.gnu.org/archive/html/bug-gnu-emacs/2009-05/msg00413.html

in my previous mail ("the updated comment" in the latter means the
above comment).

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Frame ordering

[martin rudalics]

 >> #ifdef NS_IMPL_COCOA
 >>        else
 >> 	/* Under NS, there is no system mechanism for choosing a new
 >> 	   window to get focus -- it is left to application code.
 >> 	   So the portion of THIS application interfacing with NS
 >> 	   needs to know about it.  We call Fraise_frame, but the
 >> 	   purpose is really to transfer focus.  */
 >> 	Fraise_frame (frame1);
 >> #endif
 >
 >> before we do switch frames.  Is this related to the issue at hand?
 >
 > I think so.  That's why I referred to
 >
 > http://lists.gnu.org/archive/html/bug-gnu-emacs/2009-05/msg00373.html
 > http://lists.gnu.org/archive/html/bug-gnu-emacs/2009-05/msg00413.html
 >
 > in my previous mail ("the updated comment" in the latter means the
 > above comment).

What's not clear to me is: Does (1) the conditional above (raising the
frame) not transfer the focus or is (2) just the comment wrong and the
raise_frame is not needed?

martin

Re: Frame ordering

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 14 Jun 2010 11:20:25 +0200, martin rudalics <rudalics@gmx.at> said:

> What's not clear to me is: Does (1) the conditional above (raising
> the frame) not transfer the focus or is (2) just the comment wrong
> and the raise_frame is not needed?

The following part is not correct.

	/* Under NS, there is no system mechanism for choosing a new
	   window to get focus -- it is left to application code.

Because Emacs 22.3 Carbon+AppKit port, Emacs 23 Mac port, and so many
other Cocoa applications are using such a mechanism, without explicit
focus switching on the deletion of a window.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Frame ordering

[Stefan Monnier]

>> What's not clear to me is: Does (1) the conditional above (raising
>> the frame) not transfer the focus or is (2) just the comment wrong
>> and the raise_frame is not needed?

> The following part is not correct.

> 	/* Under NS, there is no system mechanism for choosing a new
> 	   window to get focus -- it is left to application code.

> Because Emacs 22.3 Carbon+AppKit port, Emacs 23 Mac port, and so many
> other Cocoa applications are using such a mechanism, without explicit
> focus switching on the deletion of a window.

So we should start by removing this NS-specific #ifdef.


        Stefan

Re: Frame ordering

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 13 Jun 2010 22:42:40 -0400, David Reitter <david.reitter@gmail.com> said:

> I think this would be a substantial, and good change to the way
> frames are ordered.  Are you OK with this?

It changes the behavior of repeated "C-x 5 o" to alternating two
frames rather than circulating all visible frames.

				     YAMAMOTO Mitsuharu
				mituhaur@math.s.chiba-u.ac.jp

Re: Frame ordering

[David Reitter]

On Jun 13, 2010, at 11:52 PM, YAMAMOTO Mitsuharu wrote:
> 
> It changes the behavior of repeated "C-x 5 o" to alternating two
> frames rather than circulating all visible frames.

Yes.  The original complaint from several users was that frame cycling does not work as expected - at least `previous-frame' should move to the previously selected frame.  Of course that implies what you are saying (if `next-frame' does the opposite of `previous-frame').

A nice solution to the issue is shown in the OS X "application switching" mechanism (Command-Tab).  If Command is held, we keep switching along the list, without entering a cycle.  If Command is released (as in Command-Tab, Command-Tab), we switch back to the previously selected frame.

Another solution might be to have `previous-frame' and `other-frame' use `norecord'.  I haven't tried this.

Re: Frame ordering

[Lennart Borgman]

On Mon, Jun 14, 2010 at 5:52 PM, David Reitter <david.reitter@gmail.com> wrote:
>
> A nice solution to the issue is shown in the OS X "application switching" mechanism (Command-Tab).  If Command is held, we keep switching along the list, without entering a cycle.  If Command is released (as in Command-Tab, Command-Tab), we switch back to the previously selected frame.

If I understand your description correctly this is exactly how this is
handled on w32 to with Alt-Tab.

What is the reason not to let the window handler do this job? Why
should Emacs do it?

Re: Frame ordering

[David Reitter]

On Jun 14, 2010, at 12:05 PM, Lennart Borgman wrote:
> 
> What is the reason not to let the window handler do this job? Why
> should Emacs do it?

Absolutely.  Up to now I've been going by the comment quoted elsewhere in this thread, stating that we'd have to do it ourselves.  

On Jun 14, 2010, at 9:29 AM, Stefan Monnier wrote:

> So we should start by removing this NS-specific #ifdef.


When I take out the NS-specific raise-frame call, the new topmost window fails to become active (key/main) after deleting a frame.  That is why we need to call raise-frame.  However, we should do so with the topmost window (rather than one determined via Vframe_list).  This is more rather than less NS-specific code.

Second, this would not affect the cycling at all.  As far as I can see, Cocoa applications use a _cycleWindows method from NSApplication, but that one is private.

NSApplication's `orderedWindows' is basically what we want.  So I would probably suggest to implement a port-specific variants of `prev_frame()', which then use the window manager's list or, if available, call any window manager API directly.

Re: Frame ordering

[Lennart Borgman]

On Mon, Jun 14, 2010 at 6:29 PM, David Reitter <david.reitter@gmail.com> wrote:
> On Jun 14, 2010, at 12:05 PM, Lennart Borgman wrote:
>>
>> What is the reason not to let the window handler do this job? Why
>> should Emacs do it?
>
> Absolutely.  Up to now I've been going by the comment quoted elsewhere in this thread, stating that we'd have to do it ourselves.

Was not what you shown (Command-Tab switching) what the window handler
on OS X does? If so then trying to interfere with that is probably a
bad idea (and is prevented actively by at least w32).

Of course internal Emacs frame switching must be handled in Emacs. I
have personally never used any command inside Emacs for frame
switching, but I can see such needs. (One of those is for example
letting C-x 5 0 show the next Emacs frame instead of what the window
manager chooses if a window manager command is used to close the
frame.)

Re: Frame ordering

[Jan Djärv]

Lennart Borgman skrev 2010-06-14 18.47:
> On Mon, Jun 14, 2010 at 6:29 PM, David Reitter<david.reitter@gmail.com>  wrote:
>> On Jun 14, 2010, at 12:05 PM, Lennart Borgman wrote:
>>>
>>> What is the reason not to let the window handler do this job? Why
>>> should Emacs do it?
>>
>> Absolutely.  Up to now I've been going by the comment quoted elsewhere in this thread, stating that we'd have to do it ourselves.
>
> Was not what you shown (Command-Tab switching) what the window handler
> on OS X does? If so then trying to interfere with that is probably a
> bad idea (and is prevented actively by at least w32).
>
> Of course internal Emacs frame switching must be handled in Emacs. I
> have personally never used any command inside Emacs for frame
> switching, but I can see such needs. (One of those is for example
> letting C-x 5 0 show the next Emacs frame instead of what the window
> manager chooses if a window manager command is used to close the
> frame.)

I haven't followed this closely, but any attempt to make Emacs do frame 
switching in X11 is doomed to failure on some window managers.  Window 
managers doesn't need to honor raise-frame.

Besides, why should C-x 5 0 select another Emacs frame? I often use a 
non-Emacs app, make a new Emacs frame, do some editing and then C-x 5 0 to get 
back to the non-Emacs app, even on OSX.

Sorry if this has been discussed before.

	Jan D.

Re: Frame ordering

[Lennart Borgman]

On Mon, Jun 14, 2010 at 7:10 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
> Lennart Borgman skrev 2010-06-14 18.47:
>>
>> (One of those is for example
>> letting C-x 5 0 show the next Emacs frame instead of what the window
>> manager chooses if a window manager command is used to close the
>> frame.)
>
> Besides, why should C-x 5 0 select another Emacs frame? I often use a
> non-Emacs app, make a new Emacs frame, do some editing and then C-x 5 0 to
> get back to the non-Emacs app, even on OSX.

Just because it would be an easy way to distinguish between the case
when I am closing an Emacs frame and want to stay in Emacs and the
case where I want the window manager decide. Easy to do, easy to
remember. (But maybe some people always wants the window manager to do
it. Then add a flag/defcustom.)

Re: Frame ordering

[David Reitter]

On Jun 14, 2010, at 12:47 PM, Lennart Borgman wrote:
> 
> Was not what you shown (Command-Tab switching) what the window handler
> on OS X does? If so then trying to interfere with that is probably a
> bad idea (and is prevented actively by at least w32).

To clarify: I spoke about application switching, not switching between the windows of a single application (A-` and A-~).
OSX and Windows follow different philosophies there.

I fully agree that one should let the window manager do it, but we want to make sure that this interacts nicely with programmatically raised frames and such.  I think this should be no problem.

If all of these things work great in GNU/Linux with whatever window manager, and on Windows, then there is no need to modify the order of frames in Vframe_list.

Re: Frame ordering

[Lennart Borgman]

On Mon, Jun 14, 2010 at 7:14 PM, David Reitter <david.reitter@gmail.com> wrote:
> On Jun 14, 2010, at 12:47 PM, Lennart Borgman wrote:
>>
>> Was not what you shown (Command-Tab switching) what the window handler
>> on OS X does? If so then trying to interfere with that is probably a
>> bad idea (and is prevented actively by at least w32).
>
> To clarify: I spoke about application switching, not switching between the windows of a single application (A-` and A-~).
> OSX and Windows follow different philosophies there.
>
> I fully agree that one should let the window manager do it, but we want to make sure that this interacts nicely with programmatically raised frames and such.  I think this should be no problem.

I see, then we misunderstood each other.

Perhaps one of the main problem with getting this to work with
programmatically raised windows is that it is sometimes hard to wait
for the relevant message from the window manager before proceeding. I
think that is necessary.

Re: Frame ordering

[Stefan Monnier]

> When I take out the NS-specific raise-frame call, the new topmost
> window fails to become active (key/main) after deleting a frame.

But that is probably due to a bug elsewhere.

> That is why we need to call raise-frame.

No: that is why we have a Fraise_frame at this place, but I think this
is a hack that leads to further trouble.  So we should remove the
Fraise_frame and then try and fix the problem in The Right Way.


        Stefan

Re: Frame ordering

[David Reitter]

Letting the window manager decide works fine.  `next-frame' switches back to the previously selected frame, so, when repeated, it'll cycle between just two frames.  `previous-frame' lets users cycle through all frames.  I feel like it should be the other way round.

Thoughts?  How do other window managers do this?


--------

diff --git a/src/frame.c b/src/frame.c
index d73d4d6..2bbcbc8 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -1076,6 +1076,7 @@ next_frame (frame, minibuf)
      Lisp_Object frame;
      Lisp_Object minibuf;
 {
+  Lisp_Object frame_list;
   Lisp_Object tail;
   int passed = 0;
 
@@ -1086,9 +1087,16 @@ next_frame (frame, minibuf)
   /* If this frame is dead, it won't be in Vframe_list, and we'll loop
      forever.  Forestall that.  */
   CHECK_LIVE_FRAME (frame);
+ 
+#if HAVE_NS
+    frame_list = ns_frame_list();
+#else
+    frame_list = Vframe_list; 
+#endif
 
   while (1)
-    for (tail = Vframe_list; CONSP (tail); tail = XCDR (tail))
+
+    for (tail = frame_list; CONSP (tail); tail = XCDR (tail))
       {
 	Lisp_Object f;
 
@@ -1164,11 +1172,17 @@ prev_frame (frame, minibuf)
     abort ();
 
   prev = Qnil;
-  for (tail = Vframe_list; CONSP (tail); tail = XCDR (tail))
+
+#if HAVE_NS
+  tail = ns_frame_list();
+#else
+  tail = Vframe_list; 
+#endif
+  for (;CONSP (tail); tail = XCDR (tail))
     {
       Lisp_Object f;
 
       f = XCAR (+
       if (!FRAMEP (f))
 	abort ();
 
diff --git a/src/nsterm.h b/src/nsterm.h
index e2d42c5..89641ff 100644
--- a/src/nsterm.h
+++ b/src/nsterm.h
@@ -779,6 +779,8 @@ extern unsigned long ns_get_rgb_color (struct frame *f,
                                        float r, float g, float b, float a);
 extern NSPoint last_mouse_motion_position;
 
+extern Lisp_Object ns_frame_list (void);  /* needed by frame.c */
+
 #ifdef NS_IMPL_GNUSTEP
 extern char gnustep_base_version[];  /* version tracking */
 #endif
diff --git a/src/nsterm.m b/src/nsterm.m
index 85f2a26..d61528e 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -911,6 +911,32 @@ ns_set_terminal_modes (struct terminal *terminal)
    ========================================================================== */
 
 
+Lisp_Object
+ns_frame_list ()
+{
+  Lisp_Object frame_list = Qnil;
+
+  NSEnumerator *e = [[NSApp orderedWindows] reverseObjectEnumerator];
+  NSWindow *win;
+  Lisp_Object frame;
+  struct frame *f;
+
+  while (win = [e nextObject]) {
+    if (! [win isKindOfClass:[EmacsWindow class]])
+      continue;
+
+    f = ((EmacsView *) [((EmacsWindow *) win) delegate])->emacsframe;
+ 
+    XSETFRAME (frame, f);
+
+    if (!FRAMEP (frame))
+      abort ();
+    frame_list = Fcons (frame, frame_list);
+  }
+  return frame_list;
+}
+
+
 static void
 ns_raise_frame (struct frame *f)
 /* --------------------------------------------------------------------------

Re: Frame ordering

[Stefan Monnier]

> Letting the window manager decide works fine.  `next-frame' switches
> back to the previously selected frame, so, when repeated, it'll cycle
> between just two frames.  `previous-frame' lets users cycle through
> all frames.  I feel like it should be the other way round.

I think we first need to figure out how to fix the bug that the
Fraise_frame is trying to workaround.  And then we'll see if further
changes are required.


        Stefan

Re: Frame ordering

[David Reitter]

On Jun 15, 2010, at 9:25 AM, Stefan Monnier wrote:
> 
> I think we first need to figure out how to fix the bug that the
> Fraise_frame is trying to workaround.  And then we'll see if further
> changes are required.


I'm not sure how fixing Fdelete_frame can possibly address the issue concerning the next/previous-frame order.  
Of course you're right that this is odd and that there probably is a bug somewhere.

delete_frame() first selects another frame before running the terminal's delete_frame_hook.  Does this make the new frame the NS key frame?
If we are not deleting a key frame, I reckon NS will not select another frame to make it key.    [NSWindow close] is called in nsterm.m's x_destroy_window()), and I think it should change the key frame if the key frame is being deleted, as [NSWindow orderOut] is documented to do.

The Appkit port does this only slightly differently:

  /* AppKit version of mac_dispose_frame_window, which is implemented
     as -[NSWindow close], will change the focus to the next window
     during its call.  So, unlike other platforms, we clean up the
     focus-related variables before calling mac_dispose_frame_window.  */

mac_dispose_frame_window (f)
     struct frame *f;
{
  NSWindow *window = FRAME_MAC_WINDOW (f);

  [window close];
}

However, the delete_frame() function in frame.c is the same - it seems to select some other frame according to Vframe_list:

On Jun 15, 2010, at 5:24 AM, YAMAMOTO Mitsuharu wrote:

> 
> That would be the behavior of "letting the window manager decide",
> i.e., no explicit code at the application side.  The Mac port also
> behaves like this.

Can you point out how your port does that?  I can't find it.  (If it is a recent change, let me know and I'll update my Appkit branch.)

Re: Frame ordering

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 14 Jun 2010 11:52:01 -0400, David Reitter <david.reitter@gmail.com> said:

> On Jun 13, 2010, at 11:52 PM, YAMAMOTO Mitsuharu wrote:
>> 
>> It changes the behavior of repeated "C-x 5 o" to alternating two
>> frames rather than circulating all visible frames.

> Yes.  The original complaint from several users was that frame
> cycling does not work as expected - at least `previous-frame' should
> move to the previously selected frame.  Of course that implies what
> you are saying (if `next-frame' does the opposite of
> `previous-frame').

> A nice solution to the issue is shown in the OS X "application
> switching" mechanism (Command-Tab).  If Command is held, we keep
> switching along the list, without entering a cycle.  If Command is
> released (as in Command-Tab, Command-Tab), we switch back to the
> previously selected frame.

As far as I tested with TextEdit.app on Mac OS X 10.6,

  Command-` Command-` Command-` ...

causes circulation and

  Command-` (mouse click) Command-` (mouse click) Command-` ...

causes alternation.  (BTW, this is bound to Command-F1 in the default
setting for Japanese language environment, maybe because "`" is not
located at the upper-left corner in the Japanese keyboard.)

That would be the behavior of "letting the window manager decide",
i.e., no explicit code at the application side.  The Mac port also
behaves like this.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Frame ordering

[martin rudalics]

 > However, I got the code below to work at the end of do_switch_frame.
[..]
 > +       Vframe_list = Fcons (frame, Fdelq (frame, Vframe_list));

I'm afraid it's more complicated than that.  You probably also want to
"bury" the "old" frame at the end of the frame list.  Which means that
you eventually might want a way to "unbury" a frame ...

martin

Re: Frame ordering

[David Reitter]

On Jun 11, 2010, at 1:13 PM, martin rudalics wrote:
> 
> I'd write a simple function to reorder frames, make it callable from
> Lisp, and test it from there first.

OK, that works. 
What next?
`handle-switch-frame' could be defined in Lisp anyway, calling the current Fhandle_switch_frame primitive.

That said, why did the same not work in do_switch_frame, and why did my other variant (that I posted) lead to hangs and crashes?



(global-set-key [switch-frame] 'my-handle-switch-frame)

(defun my-handle-switch-frame ( event)
 (interactive "e")
 (handle-switch-frame event)
 (set-latest-frame (selected-frame)))


DEFUN ("set-latest-frame", Fset_latest_frame, Sset_latest_frame, 1, 1, 0,
      doc: /* Make FRAME the last frame in the frame list. */)
    (frame)
    Lisp_Object frame;
{
 if (NILP (frame))
   frame = selected_frame;
 if (!FRAMEP (frame))
   return Qnil;
 Vframe_list = Fcons (frame, Fdelq (frame, Vframe_list));
 return Qnil;  /* don't return the new frame-list - see Fframe_list */
}

Re: Frame ordering

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 11 Jun 2010 08:29:23 -0400, David Reitter <david.reitter@gmail.com> said:

> Currently, frames seem to be selected in order of their creation;
> deleting a frame does not select the previously created frame, but
> the frame that was created before it.  Many users (e.g., see below)
> find this annoying, and so do I.

If you mean the behavior that C-x 5 2, C-x 5 2, C-x 5 o, C-x 5 0
selects the oldest frame rather than the youngest one, that is
specific to the NS port.  The behavior might depend on the window
manager as for X11, but at least X11 builds with the default X11
window manager (quartz-wm) on Mac OS X, as well as the Mac port,
select the youngest frame.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp