From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: a little feedback on Cocoa Emacs.app Date: Mon, 4 Aug 2008 12:56:36 -0400 Message-ID: <25E49984-75A7-4879-93B5-22C240F8950C@gnu.org> References: <4358E889-E5D2-4E68-83D3-E6AB9C03F7B5@gnu.org> <508B5967-EAA1-4DEA-8533-19E4C0CD4ECF@gnu.org> <9F4D1718-BBB2-489C-8124-35189C98775E@gnu.org> <2616537B-2ECE-4C20-B707-3C802DC4C10D@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v928.1) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1217869039 16223 80.91.229.12 (4 Aug 2008 16:57:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 Aug 2008 16:57:19 +0000 (UTC) Cc: emacs-devel@gnu.org To: Adrian Robert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 04 18:58:10 2008 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.50) id 1KQ3Nk-0008SV-Et for ged-emacs-devel@m.gmane.org; Mon, 04 Aug 2008 18:58:04 +0200 Original-Received: from localhost ([127.0.0.1]:56145 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KQ3Mo-0005dY-Pt for ged-emacs-devel@m.gmane.org; Mon, 04 Aug 2008 12:57:06 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KQ3Mj-0005aj-3y for emacs-devel@gnu.org; Mon, 04 Aug 2008 12:57:01 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KQ3Mh-0005Zb-Nk for emacs-devel@gnu.org; Mon, 04 Aug 2008 12:57:00 -0400 Original-Received: from [199.232.76.173] (port=53191 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KQ3Mh-0005ZY-Gs for emacs-devel@gnu.org; Mon, 04 Aug 2008 12:56:59 -0400 Original-Received: from raeburn.org ([69.25.196.97]:20009) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KQ3MU-0008C6-Ij; Mon, 04 Aug 2008 12:56:53 -0400 Original-Received: from NOME-KING.MIT.EDU (NOME-KING.MIT.EDU [18.18.1.160]) by raeburn.org (8.14.1/8.14.1) with ESMTP id m74GuaeM017438; Mon, 4 Aug 2008 12:56:37 -0400 (EDT) In-Reply-To: <2616537B-2ECE-4C20-B707-3C802DC4C10D@gmail.com> X-Mailer: Apple Mail (2.928.1) X-detected-kernel: by monty-python.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:102047 Archived-At: On Aug 4, 2008, at 08:50, Adrian Robert wrote: >> I haven't yet waded through enough of the menu handling code to >> figure out if it's easy to make it dynamic and updated from lisp, >> but I threw together code to add a fixed one-element menu, not >> conditionalized on which flavor of NS support is used. > > When you say "one-element", you mean it adds the one element to the > existing standard dock menu provided by the system, or it replaces > it? I'd prefer adding.. > > If it adds (or we can get the patch into that form) I'd be inclined > to accept it now, because it is only altering an existing (Cocoa- > generated) menu. Adding a dynamic lisp-based menu would be a new > feature and I'd have that wait. It appears that the items of the menu you define get slipped in between the list of windows and the standard set of actions in the menu that pops up. >> Using the keyboard commands to delete a frame get that result; >> clicking on buttons with the mouse can make the application go away. > > This sounds like a bug. Shouldn't it have the same behavior > regardless of whether close from mouse or keyboard? I'm comfortable enough with the way things have worked for a while that this doesn't seem like an issue to me. The lack of consistency of the new Mac UI with the way the rest of it works does, though. (Well, I haven't checked the Windows version.) If you want to argue that all window-system versions should behave the way the Cocoa port does now, go for it. But unless/until you win that argument, I think the Cocoa port should change. A variation I'd be more interested in, though, might be the ability to run window-less. Much like some Mac apps will let you close the last window, but keep running, and let you open new windows (or quit) through the menus that are displayed even without any open windows. I don't know if there's a good analog for this behavior for X11 and Windows, though, so I'm not going to hold my breath. > You've stumbled onto another FOR-RELEASE item: > > ** finish handle terminate request (user logout) > > I'd definitely appreciate help on this one because it ought to be > simple but I seem to be unable to get it working.. take a look at > [EmacsApp -applicationShouldTerminate:] in nsterm.m... Probably getting out of my depth in Cocoa and Objective C, but I'll try to take a look tonight. Ken