[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: a little feedback on Cocoa Emacs.app
From: |
Ken Raeburn |
Subject: |
Re: a little feedback on Cocoa Emacs.app |
Date: |
Mon, 4 Aug 2008 06:15:50 -0400 |
On Jul 27, 2008, at 22:34, Adrian Robert wrote:
On Jul 27, 2008, at 12:45 PM, Ken Raeburn wrote:
4) under Spaces, I found it kind of annoying not to have a
"new window" option in the dock menu
This seems like something it would be better if Apple fixed, since
it
affects all applications. Have you reported it to them? It could
be
added to Emacs.app pretty easily I think, though right now
priorities
are on bug-fixing and code cleanup.
"New window" isn't something all applications support. For those
that do support creating new windows, like Mail, sometimes you have
to create specific types of windows (new message, new message
viewer). I'm not sure what Apple could do in the generic case,
Ah, OK, I added it to FOR-RELEASE. Would you like to work on it? ;)
(back in the country now, and with just a few cycles to spare...)
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. It says "new frame", not "new
window" like some other apps use, for consistency with the other Emacs
menus and terminology. My first, very small foray into Objective C....
I've attached the current patch for feedback.
This seems kind of like a new (though minor) feature to me, and we're
in feature freeze now, though this did get into nextstep/FOR-RELEASE.
Does it belong in Emacs 23.1? (If so, I think I'd just put in the
fixed menu, not the lisp-based version I haven't figured out yet,
unless that's *really* easy and straightforward.)
Actually, in my experience, the close button or equivalent on the
last Emacs window causes Emacs to quit, in X, Carbon, and Windows
versions; the Cocoa version is behaving differently by ignoring it.
This must have changed.. it used to do nothing and say "attempted to
delete last or sole visible frame" or something like that. On the
other hand, I can't find any code in the NS port that seems to
pertain to this, so I'm not sure where the special behavior is
coming from. Hmm..
Using the keyboard commands to delete a frame get that result;
clicking on buttons with the mouse can make the application go away.
I've also noticed another odd thing in the UI (in my unpatched build
from around July 22nd or 24th, as well as my new executable):
"Quit" from the dock menu gets me a prompt asking if I want to quit.
Many (most?) Mac apps don't ask, at least if I don't have unsaved
work. Emacs 22 didn't with C-x C-c, nor did CVS Emacs when I built
the Cocoa version a week or so ago. (Current CVS Emacs crashes if I
try to build it on the Mac without the NS support.)
Once that dialog comes up, it and the menu bar seem to be the only
things that respond to input. The buttons in the dialog blink if I
click on them. The menu bar menus come up, and go away when I select
something. But I can't type into the buffer windows, and the process
doesn't go away, even if I confirm in the dialog a bunch of times or
select "Exit Emacs" from the File menu. The dialog will go away if I
select another application and then switch back to Emacs, but it
doesn't seem to help me regain control.
It could jump right into save-buffers-kill-emacs, but I haven't played
with the multi-tty stuff yet; if we support tty+nextstep then maybe it
shouldn't kill a connected tty session. C-x C-c is bound to save-
buffers-kill-terminal, not save-buffers-kill-emacs, so perhaps that's
what it should do.
Ken
dockmenu-patch.txt
Description: Text document