From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: YAMAMOTO Mitsuharu Newsgroups: gmane.emacs.devel Subject: Re: Frame ordering Date: Tue, 15 Jun 2010 18:24:47 +0900 Organization: Faculty of Science, Chiba University Message-ID: References: <8F18E079-3351-4398-B76B-6CF9169ACE9E@gmail.com> <4C123889.5060801@gmx.at> <597D28BE-ABE3-4FFF-84B1-1FBF9931293C@gmail.com> <4C126EA5.1050509@gmx.at> <4DF4317D-522E-4948-9C19-ED1252BF36B2@gmail.com> <4C133EDF.8070407@gmx.at> <77C00490-801D-47B9-83BC-32D786F1F684@gmail.com> <1F24A2FE-EF86-4E03-84CF-69748A482C64@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Trace: dough.gmane.org 1276593915 26764 80.91.229.12 (15 Jun 2010 09:25:15 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 15 Jun 2010 09:25:15 +0000 (UTC) Cc: martin rudalics , Stefan Monnier , Emacs-Devel devel To: David Reitter Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 15 11:25:14 2010 connect(): No such file or directory Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OOSOM-0003jC-FX for ged-emacs-devel@m.gmane.org; Tue, 15 Jun 2010 11:25:10 +0200 Original-Received: from localhost ([127.0.0.1]:51394 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOSOL-000365-LC for ged-emacs-devel@m.gmane.org; Tue, 15 Jun 2010 05:25:09 -0400 Original-Received: from [140.186.70.92] (port=54729 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOSO8-00032h-4k for emacs-devel@gnu.org; Tue, 15 Jun 2010 05:24:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OOSO6-0004qa-JX for emacs-devel@gnu.org; Tue, 15 Jun 2010 05:24:56 -0400 Original-Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:50476) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OOSO6-0004pq-3y for emacs-devel@gnu.org; Tue, 15 Jun 2010 05:24:54 -0400 Original-Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id D091FC0557; Tue, 15 Jun 2010 18:24:47 +0900 (JST) In-Reply-To: User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) X-detected-operating-system: by eggs.gnu.org: NetBSD 3.0 (DF) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:125947 Archived-At: >>>>> On Mon, 14 Jun 2010 11:52:01 -0400, David Reitter 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