bug#4513: NS: File menu missing

bug#4513: NS: File menu missing

[Glenn Morris]

David Reitter wrote:

> package: ns

Just in case you were unaware, if you don't put bugs in the "emacs"
package as well, none of the correspondence gets sent out to the
bug-gnu-emacs list (maybe this was intentional?). Ie, use:

Package: emacs,ns

(I hope these messages doesn't sound like a list of lectures/complaints.)

bug#4513: NS: File menu missing

[David Reitter]

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

On Sep 21, 2009, at 9:00 PM, Adrian Robert wrote:
>> The file menu is missing; its contents are in the application menu  
>> (titled "Emacs"), and the usual contents of the application menu  
>> are completely gone.
>>
>> So I've got "Emacs Edit Options"
>
> Very odd.  I have not made any changes that I *think* could affect  
> this.  Have not seen the bug (10.4) -- even tried setting my lang to  
> German, but it might be I need to do another bootstrap build or  
> something.  There look like there were a lot of menu-related changes  
> in the lisp subdirectory on 2009-09-17.

OK, so it seems to me that the culprit may be:

       [menu clear];

in ns_update_menubar.

Removing the [menu clear] brings the File menu back.

I can't find the implementation of EmacsMenu's -clear, and it is not  
documented as a NSMenu (or NSObject) function.
This makes me think it's something undocumented implemented by the  
AppKit framework.  Didn't manage to class-dump that framework.

If the behavior of -clear has changed in the 10.6 SDK in this respect,  
I would not be surprised if, when compiled on 10.6, it may link  
against the new behavior (clearing everything), and when compiled on  
10.5, it's the old one.

If OS X forces the first menu to be the application name (and I think  
it does, see Info.plist setting), then we get the behavior I'm  
observing.

The patch below seems to do the job.  Hope this works in Nextstep as  
well.
I'll check that in unless you see a problem.


diff --git a/src/nsterm.h b/src/nsterm.h
index 96f65d2..c4935f2 100644
--- a/src/nsterm.h
+++ b/src/nsterm.h
@@ -118,7 +118,6 @@ along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/ 
 >.  */
  - (NSMenuItem *)addItemWithWidgetValue: (void *)wvptr;
  - (void)fillWithWidgetValue: (void *)wvptr;
  - (EmacsMenu *)addSubmenuWithTitle: (char *)title forFrame: (struct  
frame *)f;
-- (void) clear;
  - (Lisp_Object)runMenuAt: (NSPoint)p forFrame: (struct frame *)f
                   keymaps: (int)keymaps;
  @end
diff --git a/src/nsmenu.m b/src/nsmenu.m
index 98a086b..f63852c 100644
--- a/src/nsmenu.m
+++ b/src/nsmenu.m
@@ -440,7 +440,10 @@ ns_update_menubar (struct frame *f, int deep_p,  
EmacsMenu *submenu)
              }
          }

-      [menu clear];
+      /* clear menu, leaving the first item (application menu) */
+      for (i = [menu numberOfItems]-1; i>0 ; i--)
+	[menu removeItemAtIndex:1];
+
        for (i = 0; i < XVECTOR (items)->size; i += 4)
  	{
  	  string = XVECTOR (items)->contents[i + 1];


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

bug#4513: NS: File menu missing

[David Reitter]

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

Further to this issue to confirm our diagnosis:



http://developer.apple.com/mac/library/releasenotes/Cocoa/AppKit.html

Backward Compatibility

One backward compatibility mechanism that is occasionally used in the  
frameworks is to check for the version of the system an application  
was built against, and if an older system, modify the behavior to be  
more compatible. This is done in cases where bad incompatibility  
problems are predicted or discovered; and most of these are listed  
below in these notes.

Typically we detect where an application was built by looking at the  
version of the System, Cocoa, AppKit, or Foundation frameworks the  
application was linked against. Thus, as a result of relinking your  
application on Leopard, you might notice different behaviors, some of  
which might cause incompatibilities.

...

NSApplication application menu item title (New since WWDC 2008)

In Leopard, the first item in the main menu (the application menu)  
would have its title modified to the empty string. In SnowLeopard,  
this is only done for apps linked on Leopard or earlier: new apps will  
not see this title modified. The title of the this menu item is  
ignored for display purposes - the application menu always reflects  
the application name.


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

bug#4513: NS: File menu missing

[David Reitter]

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

On Sep 23, 2009, at 10:24 PM, Adrian Robert wrote:
> OK, after seeing this I'm more inclined to go with "ignore first  
> item at top level on OS X".
>
> (We have: 10.0-10.5.8 = @Apple, 10.5.8 = @"", 10.6+ = @<appname>.   
> Jeez...)

For now I went with the smallest change possible (checking for  
@"Emacs" in addition to the others) as I don't know about NS and  
future changes in NS.
This solution relies on only what is documented.

Suppose you could indeed adopt my earlier patch if this proves  
problematic.  No need for -clear anyways, unless it is used elsewhere.

D

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

bug#4513: marked as done (NS: File menu missing)

[Emacs bug Tracking System]

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

Your message dated Fri, 25 Sep 2009 13:45:14 -0400
with message-id <95462120-61BD-4BB0-AF5D-A69FE1F4A480@gmail.com>
and subject line Re: bug#4513: NS: File menu missing
has caused the Emacs bug report #4513,
regarding NS: File menu missing
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com
immediately.)


-- 
4513: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=4513
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 4958 bytes --]

From: David Reitter <david.reitter@gmail.com>
To: emacs-pretest-bug@gnu.org
Subject: NS: File menu missing
Date: Mon, 21 Sep 2009 18:55:31 -0400
Message-ID: <6C67AAF0-3E49-48EF-8553-0CB7F9AC97F7@gmail.com>

package: ns
X-Debbugs-Cc: Adrian Robert <adrian.b.robert@gmail.com>


The file menu is missing; its contents are in the application menu  
(titled "Emacs"), and the usual contents of the application menu are  
completely gone.

So I've got "Emacs Edit Options"

Is this intentional (if so which change - had a long hard look at  
change logs)?

Have been trying to debug without success so far.

This was introduced at some point in between the Emacs 23.1 pretest  
branch cut and the current master branch.


Thanks
- David

In GNU Emacs 23.1.50.7 (i386-apple-darwin10.0.0, NS apple- 
appkit-1038.11)
  of 2009-09-21 on scarlett.psy.cmu.edu
Windowing system distributor `Apple', version 10.3.1038
configured using `configure  '--with-ns' '--without-x' 'CC=gcc -arch  
i386''

Important settings:
   value of $LC_ALL: nil
   value of $LC_COLLATE: en_US.us-ascii
   value of $LC_CTYPE: en_US.us-ascii
   value of $LC_MESSAGES: en_US.us-ascii
   value of $LC_MONETARY: en_US.us-ascii
   value of $LC_NUMERIC: en_US.us-ascii
   value of $LC_TIME: en_US.us-ascii
   value of $LANG: de_DE.ISO8859-15
   value of $XMODIFIERS: nil
   locale-coding-system: us-ascii-unix
   default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
   tooltip-mode: t
   mouse-wheel-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   global-auto-composition-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t
   line-number-mode: t
   transient-mark-mode: t

Recent input:
<menu-bar> <help-menu> <send-emacs-bug-report>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.



[-- Attachment #3: Type: message/rfc822, Size: 6876 bytes --]

[-- Attachment #3.1.1: Type: text/plain, Size: 577 bytes --]

On Sep 23, 2009, at 10:24 PM, Adrian Robert wrote:
> OK, after seeing this I'm more inclined to go with "ignore first  
> item at top level on OS X".
>
> (We have: 10.0-10.5.8 = @Apple, 10.5.8 = @"", 10.6+ = @<appname>.   
> Jeez...)

For now I went with the smallest change possible (checking for  
@"Emacs" in addition to the others) as I don't know about NS and  
future changes in NS.
This solution relies on only what is documented.

Suppose you could indeed adopt my earlier patch if this proves  
problematic.  No need for -clear anyways, unless it is used elsewhere.

D

[-- Attachment #3.1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]