a little feedback on Cocoa Emacs.app

a little feedback on Cocoa Emacs.app

[Ken Raeburn]

A few early comments on Emacs.app, on Leopard:

1) Nice!  It built easily and launched without a problem.  My .emacs  
code was thrown off a little by the change in window-system value, but  
that's the only problem I've noticed so far.  (I've only used it for a  
little while, though.)

2) Thank you for putting the size into the title bar while resizing!   
Its absence was one of the most annoying things I found about the old  
Carbon app.

3) I was surprised to see that the new Emacs.app is smaller than the  
old (Carbon) one.  Then I noticed that there are no info files in the  
new one; is that intentional?

4) You didn't fix the other thing I found annoying about Carbon  
Emacs :-) ... under Spaces, I found it kind of annoying not to have a  
"new window" option in the dock menu, so I can cause a new window to  
come up without first having to select the application (which in  
Spaces can cause a switch to a different space, then I have to create  
the new window and then move it back to the space I want to use it  
in).  Would this be tough to add?  I know nothing about the relevant  
APIs....

5) The close button seems to be disabled when there's only one  
window.  I'd rather see it quit Emacs like it used to in Carbon Emacs,  
or be configurable to allow that.  Some apps will keep running with no  
windows open, since you can open new ones from the menus or whatever,  
but that may be too big a change for Emacs.

6) The File menu includes "make frame on display..." but as far as I  
know, the display name parameter isn't used except under X, is it?   
(The documentation specifically refers to X.)  Since "make frame" is  
already there, this seems redundant.

Ken

Re: a little feedback on Cocoa Emacs.app

[Adrian Robert]

Ken Raeburn <raeburn <at> gnu.org> writes:

> 3)  I noticed that there are no info files in the  
> new one; is that intentional?

No, this was an error in the installation commands.  Fixed in CVS
(Makefile.in).


> 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.


 
> 5) The close button seems to be disabled when there's only one  
> window.  I'd rather see it quit Emacs like it used to in Carbon Emacs,  
> or be configurable to allow that

Emacs.app follows emacs interfaces on other platforms here.  It is possible
that adding a configurable option as you suggest would be acceptable.  Do you
know if it is the plain Carbon Emacs that has this behavior, or is it only in
the distributions (Carbon Emacs Package, Aquamacs, etc.)?



> 6) The File menu includes "make frame on display..." but as far as I  
> know, the display name parameter isn't used except under X, is it?   
> (The documentation specifically refers to X.)  Since "make frame" is  
> already there, this seems redundant.

True.  When "ns-extended-platform-support-mode" is enabled, this issue is
fixed.  (This mode may be removed from emacs CVS soon though.)


Thanks for your feedback!

Re: a little feedback on Cocoa Emacs.app

[Stefan Monnier]

>> 6) The File menu includes "make frame on display..." but as far as I
>> know, the display name parameter isn't used except under X, is it?
>> (The documentation specifically refers to X.)  Since "make frame" is
>> already there, this seems redundant.

> True.  When "ns-extended-platform-support-mode" is enabled, this issue is
> fixed.  (This mode may be removed from emacs CVS soon though.)

I don't think this needs to depend on ns-extended-platform-support-mode:
make-frame-on-display is basically a feature that is not supported under
Cocoa (IIUC it is supported under GNUstep), so the corresponding menu
entry should be removed/disabled.


        Stefan

Re: a little feedback on Cocoa Emacs.app

[Ken Raeburn]

On Jul 27, 2008, at 03:29, Adrian Robert wrote:
> Ken Raeburn <raeburn <at> gnu.org> writes:
>
>> 3)  I noticed that there are no info files in the
>> new one; is that intentional?
> No, this was an error in the installation commands.  Fixed in CVS
> (Makefile.in).

Good, thanks.

>> 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, aside from maybe  
"select application without switching spaces", which would be a  
different model for how Spaces would work, a significant UI change,  
and a change in the wrong direction for those apps that support only  
one window.  Creating application-specific entries in the dock menu,  
on the other hand, is obviously already supported in general, and lets  
the application do whatever's appropriate for it, even if it's a  
little more work for the app writer.


>> 5) The close button seems to be disabled when there's only one
>> window.  I'd rather see it quit Emacs like it used to in Carbon  
>> Emacs,
>> or be configurable to allow that
>
> Emacs.app follows emacs interfaces on other platforms here.  It is  
> possible
> that adding a configurable option as you suggest would be  
> acceptable.  Do you
> know if it is the plain Carbon Emacs that has this behavior, or is  
> it only in
> the distributions (Carbon Emacs Package, Aquamacs, etc.)?

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.

I was using a Carbon Emacs I built from the main CVS repository with  
the make-package script.

Ken

Re: a little feedback on Cocoa Emacs.app

[Adrian Robert]

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?  ;)



>>> 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..

Re: a little feedback on Cocoa Emacs.app

[Ken Raeburn]

[-- Attachment #1: Type: text/plain, Size: 3698 bytes --]

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


[-- Attachment #2: dockmenu-patch.txt --]
[-- Type: text/plain, Size: 3153 bytes --]

2008-08-04  Ken Raeburn  <raeburn@raeburn.org>

	* nsterm.h (dockMenu): Declare variable.
	* nsmenu.m (dockMenu): Define it.
	* nsterm.m (ns_term_init): Initialize it to a new menu.
	(applicationDockMenu, newFrame): New EmacsApp methods.

Index: nsmenu.m
===================================================================
RCS file: /cvsroot/emacs/emacs/src/nsmenu.m,v
retrieving revision 1.8
diff -p -u -r1.8 nsmenu.m
--- nsmenu.m	1 Aug 2008 14:01:07 -0000	1.8
+++ nsmenu.m	4 Aug 2008 09:26:25 -0000
@@ -63,7 +63,7 @@ extern Lisp_Object Voverriding_local_map
 		   Qoverriding_local_map, Qoverriding_terminal_local_map;
 
 extern long context_menu_value;
-EmacsMenu *mainMenu, *svcsMenu;
+EmacsMenu *mainMenu, *svcsMenu, *dockMenu;
 
 /* NOTE: toolbar implementation is at end,
   following complete menu implementation. */
Index: nsterm.h
===================================================================
RCS file: /cvsroot/emacs/emacs/src/nsterm.h,v
retrieving revision 1.9
diff -p -u -r1.9 nsterm.h
--- nsterm.h	1 Aug 2008 16:29:50 -0000	1.9
+++ nsterm.h	4 Aug 2008 09:26:25 -0000
@@ -355,7 +355,7 @@ along with GNU Emacs.  If not, see <http
 @end
 
 extern NSArray *ns_send_types, *ns_return_types;
-extern EmacsMenu *mainMenu, *svcsMenu;
+extern EmacsMenu *mainMenu, *svcsMenu, *dockMenu;
 
 /* Apple removed the declaration, but kept the implementation */
 #if defined (NS_IMPL_COCOA) && MAC_OS_X_VERSION_MIN_REQUIRED >= MAC_OS_X_VERSION_10_4
Index: nsterm.m
===================================================================
RCS file: /cvsroot/emacs/emacs/src/nsterm.m,v
retrieving revision 1.21
diff -p -u -r1.21 nsterm.m
--- nsterm.m	3 Aug 2008 20:34:00 -0000	1.21
+++ nsterm.m	4 Aug 2008 09:26:25 -0000
@@ -3884,6 +3884,7 @@ ns_term_init (Lisp_Object display_name)
     appMenu = [[EmacsMenu alloc] initWithTitle: @"Emacs"];
     [appMenu setAutoenablesItems: NO];
     mainMenu = [[EmacsMenu alloc] initWithTitle: @""];
+    dockMenu = [[EmacsMenu alloc] initWithTitle: @""];
 
     [appMenu insertItemWithTitle: @"About Emacs"
                           action: @selector (orderFrontStandardAboutPanel:)
@@ -3922,6 +3923,10 @@ ns_term_init (Lisp_Object display_name)
                            keyEquivalent: @""
                                  atIndex: 0];
     [mainMenu setSubmenu: appMenu forItem: item];
+    [dockMenu insertItemWithTitle: @"New Frame"
+			   action: @selector (newFrame:)
+		    keyEquivalent: @""
+			  atIndex: 0];
 
     [NSApp setMainMenu: mainMenu];
     [NSApp setAppleMenu: appMenu];
@@ -4029,6 +4034,11 @@ ns_term_shutdown (int sig)
   [prefsController showForFrame: SELECTED_FRAME ()];
 }
 
+- (void)newFrame: (id)sender
+{
+  Feval (Fcons (intern ("make-frame"), Qnil));
+}
+
 
 /* Open a file (used by below, after going into queue read by ns_read_socket) */
 - (BOOL) openFile: (NSString *)fileName
@@ -4150,6 +4160,11 @@ fprintf (stderr, "res = %d\n", EQ (res, 
   ns_send_appdefined (-1);
 }
 
+/* Handle dock menu requests.  */
+- (NSMenu *)applicationDockMenu: (NSApplication *) sender
+{
+  return dockMenu;
+}
 
 
 /* ==========================================================================

[-- Attachment #3: Type: text/plain, Size: 1 bytes --]

Re: a little feedback on Cocoa Emacs.app

[mituharu]

> 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.

>  +- (void)newFrame: (id)sender
>  +{
>  +  Feval (Fcons (intern ("make-frame"), Qnil));
>  +}
>  +

Strictly speaking, Feval calls inside read_socket_hook are not
allowed by design, although the Cocoa/GNUstep port is using it
extensively...

BTW, it's not difficult to add a *static* dock menu to Carbon
Emacs 22 CVS, either.  For example, add

  err = CreateNewMenu (MAC_MENU_END, 0, &menu);
  if (err == noErr)
    err = AppendMenuItemTextWithCFString (menu, CFSTR ("New Frame"),
					  0, kHICommandNew, NULL);
  if (err == noErr)
    SetApplicationDockTileMenu (menu);

at the end of the `#ifdef MAC_OSX' part of init_menu_bar in
src/mactoolbox.c, and

  (put 'new 'mac-apple-event-id "new ") ; kHICommandNew
  (define-key mac-apple-event-map [hi-command new] 'make-frame)

to lisp/term/mac-win.el.

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

Re: a little feedback on Cocoa Emacs.app

[Adrian Robert]

On Aug 4, 2008, at 8:42 AM, mituharu@math.s.chiba-u.ac.jp wrote:

>> +- (void)newFrame: (id)sender
>> +{
>> +  Feval (Fcons (intern ("make-frame"), Qnil));
>> +}
>> +
>
> Strictly speaking, Feval calls inside read_socket_hook are not
> allowed by design, although the Cocoa/GNUstep port is using it
> extensively...

Yes.. I was going to change this to use an alternative method similar  
to your patch below before committing.  And the other Fevals are still  
slated for removal -- just been a lot of higher-priority items since  
the previous discussion.


>    err = AppendMenuItemTextWithCFString (menu, CFSTR ("New Frame"),
> 					  0, kHICommandNew, NULL);
> ...
>  (put 'new 'mac-apple-event-id "new ") ; kHICommandNew
>  (define-key mac-apple-event-map [hi-command new] 'make-frame)

Re: a little feedback on Cocoa Emacs.app

[Adrian Robert]

On Aug 4, 2008, at 6:15 AM, Ken Raeburn wrote:

> 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
>>>> ...
> (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.

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.



>>>>> 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.

This sounds like a bug.  Shouldn't it have the same behavior  
regardless of whether close from mouse or keyboard?



> 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.
...
>
> 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.

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...

Re: a little feedback on Cocoa Emacs.app

[Ken Raeburn]

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

Re: a little feedback on Cocoa Emacs.app

[Dan Nicolaescu]

Ken Raeburn <raeburn@gnu.org> writes:

  > 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.

This behavior has been on the wish list for X11 for a while...  It might
not even be that hard to implement, but nobody has volunteered to do it
so far.

Re: a little feedback on Cocoa Emacs.app

[Justin Bogner]

Dan Nicolaescu wrote:
> Ken Raeburn <raeburn@gnu.org> writes:
> 
>   > 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.
> 
> This behavior has been on the wish list for X11 for a while...  It might
> not even be that hard to implement, but nobody has volunteered to do it
> so far.
> 

With multi-tty, this behaviour could be fairly sane via the 
client-server model. That is to say, if the server were allowed to run 
without a window, you would have this behaviour.

Obviously this is a discussion for after the freeze though...

Re: a little feedback on Cocoa Emacs.app

[Dan Nicolaescu]

Justin Bogner <mail@justinbogner.com> writes:

  > Dan Nicolaescu wrote:
  > > Ken Raeburn <raeburn@gnu.org> writes:
  > >
  > >   > 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.
  > >
  > > This behavior has been on the wish list for X11 for a while...  It might
  > > not even be that hard to implement, but nobody has volunteered to do it
  > > so far.
  > >
  > 
  > With multi-tty, this behaviour could be fairly sane via the
  > client-server model. That is to say, if the server were allowed to run
  > without a window, you would have this behaviour.

That's exactly what the missing part is: being able to run without a
frame.

Re: a little feedback on Cocoa Emacs.app

[Ken Raeburn]

On Aug 4, 2008, at 13:04, Dan Nicolaescu wrote:
> Ken Raeburn <raeburn@gnu.org> writes:
>
>> 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.
>
> This behavior has been on the wish list for X11 for a while...  It  
> might
> not even be that hard to implement, but nobody has volunteered to do  
> it
> so far.

Are there specific ideas for how to keep talking to Emacs in that case  
other than emacsclient or gnuclient to tell it to run make-frame, or  
is that the way?  (Which reminds me... my old usage pattern for Emacs  
used to be to run Emacs on the local X display while in front of the  
machine, and tell it to invoke make-frame-on-display over ssh when  
logged in remotely.  One Emacs process, one long-lived Gnus session,  
etc.  I'd really like to be able to do something like that now, but  
with the local display on my Mac using the NS support, which means  
supporting both X and NS in one executable, and in one process....  I  
also tended to have -- on the local display -- a minibuffer-only  
frame, and zero or more minibuffer-less editing frames, so I could  
certainly have no editing frames open at times, though there was  
always the minibuffer at least.)

I'm mostly just curious; I doubt I'd have time to do anything about  
this myself any time soon.

Ken

Re: a little feedback on Cocoa Emacs.app

[Dan Nicolaescu]

Ken Raeburn <raeburn@gnu.org> writes:

  > On Aug 4, 2008, at 13:04, Dan Nicolaescu wrote:
  > > Ken Raeburn <raeburn@gnu.org> writes:
  > >
  > >> 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.
  > >
  > > This behavior has been on the wish list for X11 for a while...  It
  > > might
  > > not even be that hard to implement, but nobody has volunteered to do
  > > it
  > > so far.
  > 
  > Are there specific ideas for how to keep talking to Emacs in that case
  > other than emacsclient or gnuclient to tell it to run make-frame, or
  > is that the way?  

IMHO emacsclient should be the way.
It could work like this: 
emacs --daemon
then use "emacsclient" to create window system frames, and "emacsclient -t"
to create terminal frames.
(There is a functionally equivalent workaround for the missing --daemon
functionality that people are using now: start "emacs -nw -fserver-start" 
in a "screen" session, and then suspend the "screen" session)
Maybe at some point emacsclient should be folded in emacs.

  > (Which reminds me... my old usage pattern for Emacs
  > used to be to run Emacs on the local X display while in front of the
  > machine, and tell it to invoke make-frame-on-display over ssh when
  > logged in remotely.  One Emacs process, one long-lived Gnus session,
  > etc.  I'd really like to be able to do something like that now, but
  > with the local display on my Mac using the NS support, which means
  > supporting both X and NS in one executable, and in one process....  

Both NS and X are not supported in one executable, never heard of anyone
planning to support that.
You can use terminal frames now when logged in remotely (via emacsclient
-t), in a 256 color terminal they work pretty well.

  > I also tended to have -- on the local display -- a minibuffer-only
  > frame, and zero or more minibuffer-less editing frames, so I could
  > certainly have no editing frames open at times, though there was
  > always the minibuffer at least.)

Unfortunately terminal frames won't work very well in this setup... 

Hope this helps.

Re: a little feedback on Cocoa Emacs.app

[Adrian Robert]

On Aug 4, 2008, at 12:56 PM, Ken Raeburn wrote:

> On Aug 4, 2008, at 08:50, Adrian Robert wrote:
>>> 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..
>>
> 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.

Cool.  I'll rework the patch a little bit (see Yamamoto-san's post)  
and apply it, maybe tomorrow.



>>> 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.

Sure, the X interface is the prototype we follow.  But does the  
different behavior when kb or mouse to close window seem right to  
you?  Is there some reason for it you can think of?  I just want to  
make sure because it seems strange, and like I say NS port has no  
specific code handling this right now (should be generic behavior that  
is seen).  (BTW, are you using GTK or non-GTK X?)



> A variation I'd be more interested in, though, might be the ability  
> to run window-less.

I agree that it might be nice and that might not be tolerated.  I  
believe Aquamacs and other distributions offer this behavior, and that  
may be the place for it to stay for now.

Re: a little feedback on Cocoa Emacs.app

[Adrian Robert]

On Aug 4, 2008, at 7:43 PM, Adrian Robert wrote:

>
> On Aug 4, 2008, at 12:56 PM, Ken Raeburn wrote:
>
>> On Aug 4, 2008, at 08:50, Adrian Robert wrote:
>>>> 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..
>>>
>> 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.
>
> Cool.  I'll rework the patch a little bit (see Yamamoto-san's post)  
> and apply it, maybe tomorrow.

This is in.  Thanks.  Have you signed copyright assignment papers with  
FSF?  I can take this patch without them, but anything else will put  
you over the limit..



>>>> 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.
>
> Sure, the X interface is the prototype we follow.  But does the  
> different behavior when kb or mouse to close window seem right to  
> you?  Is there some reason for it you can think of?  I just want to  
> make sure because it seems strange, and like I say NS port has no  
> specific code handling this right now (should be generic behavior  
> that is seen).  (BTW, are you using GTK or non-GTK X?)

Actually I stand corrected on one point -- the NS port did have some  
code shortcircuiting delete-frame request when <= 1 frame left.  I  
took this out.  I'm not happy about it because the behavior now seems  
like a bug as I say, but no one else is speaking up so I'll not worry  
about it for now.

Also, regarding your report about the dialog appearing when you select  
Quit from dock menu, it's still there, but I fixed a bug in some  
cleanup changes of Jul 17 that was causing dialogs to fail.

Re: a little feedback on Cocoa Emacs.app

[Ken Raeburn]

On Aug 4, 2008, at 23:05, Adrian Robert wrote:
> This is in.  Thanks.

Thanks for merging it in.  I'll update and try out the fixed-up version.

>  Have you signed copyright assignment papers with FSF?  I can take  
> this patch without them, but anything else will put you over the  
> limit..

Yes, it's been on file for a while now.

> Actually I stand corrected on one point -- the NS port did have some  
> code shortcircuiting delete-frame request when <= 1 frame left.  I  
> took this out.  I'm not happy about it because the behavior now  
> seems like a bug as I say, but no one else is speaking up so I'll  
> not worry about it for now.

Thanks.

> Also, regarding your report about the dialog appearing when you  
> select Quit from dock menu, it's still there, but I fixed a bug in  
> some cleanup changes of Jul 17 that was causing dialogs to fail.

It looks like I won't get to play with it much tonight, but maybe I'll  
get a chance later in the week to have a look.  I was seeing some  
brokenness with the default directory too that I want to look at, if  
it hasn't already been fixed.

Ken

Re: a little feedback on Cocoa Emacs.app

[Adrian Robert]

On Aug 5, 2008, at 12:01 AM, Ken Raeburn wrote:

>> It looks like I won't get to play with it much tonight, but maybe  
>> I'll get a chance later in the week to have a look.  I was seeing  
>> some brokenness with the default directory too that I want to look  
>> at, if it hasn't already been fixed.

OK, I think you're talking about: start from Finder, do Ctrl-x Ctrl-f,  
and it starts you in "/".  I've checked in a fix to emacs.c.  (Bug  
related to the Carbon removal and the ambiguous MAC_OSX #define.)