From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Reitter Newsgroups: gmane.emacs.devel Subject: Re: Frame ordering Date: Mon, 14 Jun 2010 12:29:47 -0400 Message-ID: <2E617238-2118-408D-8939-80C50A2CB9FB@gmail.com> 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 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1276533322 598 80.91.229.12 (14 Jun 2010 16:35:22 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 14 Jun 2010 16:35:22 +0000 (UTC) Cc: martin rudalics , Stefan Monnier , YAMAMOTO Mitsuharu , Emacs-Devel devel To: Lennart Borgman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 14 18:35:19 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 1OOCd5-0007Dp-4Z for ged-emacs-devel@m.gmane.org; Mon, 14 Jun 2010 18:35:19 +0200 Original-Received: from localhost ([127.0.0.1]:54339 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOCd4-000258-Aj for ged-emacs-devel@m.gmane.org; Mon, 14 Jun 2010 12:35:18 -0400 Original-Received: from [140.186.70.92] (port=51689 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOCXn-0006fk-NM for emacs-devel@gnu.org; Mon, 14 Jun 2010 12:29:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OOCXm-0003IK-CR for emacs-devel@gnu.org; Mon, 14 Jun 2010 12:29:51 -0400 Original-Received: from mail-vw0-f41.google.com ([209.85.212.41]:53712) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OOCXm-0003IC-7R for emacs-devel@gnu.org; Mon, 14 Jun 2010 12:29:50 -0400 Original-Received: by vws5 with SMTP id 5so1782661vws.0 for ; Mon, 14 Jun 2010 09:29:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=MLDtKOXr1GoOwSAnmhGBRmRh+faPxuNweZopS+1kA3w=; b=nnq/dJEQOHnE/3LLAgn5NPlVAYYDSQhmlHtgN+nYEGw0pWt/O1i9K7NZijtqrkhF3A ibP3qrT3brSoRt7la6YS8pkJwDR0fEX1K6IYRqeL3Zz8ro1Vh786Qm61B3WY/N9FOrDM MZzSJFo12x06KH/VIy4g0nmRdwWivVzP6P4zU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=UKaX9hm2/sTuahrebNxK/wbJ6mGI+oyA5aIAk9Kt754q3sQ0mIbhfUIggmBz4mP+zG 7C5Av56VkmU/CMcKnRBztCUvIW9e98Q8lR87F0WxedBndibf/OwgTkEujg/KhsXaLYfP H+w9nXf+CYXJjs7ng1eBF5gvnELt6iai7t4+I= Original-Received: by 10.220.62.196 with SMTP id y4mr2954953vch.242.1276532989606; Mon, 14 Jun 2010 09:29:49 -0700 (PDT) Original-Received: from elin.psy.cmu.edu (ELIN.PSY.CMU.EDU [128.2.248.190]) by mx.google.com with ESMTPS id x4sm4469839vcr.0.2010.06.14.09.29.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 14 Jun 2010 09:29:48 -0700 (PDT) In-Reply-To: X-Mailer: Apple Mail (2.1078) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) 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:125916 Archived-At: On Jun 14, 2010, at 12:05 PM, Lennart Borgman wrote: >=20 > 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. =20 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.=