Cocoa Emacs

Cocoa Emacs

[Kazu Yamamoto]

Hello,

I have compiled Cocoa Emacs. I would like to report two things:

1) Cocoa Emacs is now using the old icon. It should use the new icon
   (mac/Emacs.app/Contents/Resources/Emacs.icns)

2) Cocoa Emacs does run in English environment. However, in Japanese
   environment, when I execute Cocoa Emacs, the icon jumps but Emacs
   frame does not appear. 

   I guess the current code relating to fonts is buggy

   Please tell me what kind of information is necessary for debug and
   how I can get it so that I can report it to this ML.

--Kazu

Re: Cocoa Emacs

[Adrian Robert]

Kazu Yamamoto <kazu <at> iij.ad.jp> writes:

Hi,

> 1) Cocoa Emacs is now using the old icon. It should use the new icon
>    (mac/Emacs.app/Contents/Resources/Emacs.icns)

OK, I've updated this in CVS (don't know where I got
the old one.. ;-/



> 2) Cocoa Emacs does run in English environment. However, in Japanese
>    environment, when I execute Cocoa Emacs, the icon jumps but Emacs
>    frame does not appear.

Hopefully the fix posted by Seiji Zenitani, which I've now
applied in CVS, improves this:

http://news.gmane.org/find-root.php?
message_id=%3c9A7F9414%2dC253%2d41A4%2dB26A%2d0DDE06B983AF%40mac.com%3e

Re: Cocoa Emacs

[Kazu Yamamoto]

Hello,

> > 1) Cocoa Emacs is now using the old icon. It should use the new icon
> >    (mac/Emacs.app/Contents/Resources/Emacs.icns)
> 
> OK, I've updated this in CVS (don't know where I got
> the old one.. ;-/
> 
> > 2) Cocoa Emacs does run in English environment. However, in Japanese
> >    environment, when I execute Cocoa Emacs, the icon jumps but Emacs
> >    frame does not appear.
> 
> Hopefully the fix posted by Seiji Zenitani, which I've now
> applied in CVS, improves this:

Both are OK. 

Thank for your quick action!

--Kazu

Cocoa Emacs

[Nick Roberts]

I'm not very familiar with Mac OS X but I have just started using a Mac at
work.  This is what I have found (using configure --with-ns):

1) The file emacs/etc/images/gud/go.xpm appears red but should be green.  This
   may be because the file uses two bytes per colour (#000080800000) while
   some icons only one, e.g., stop.xpm (#cc0033) but it gets rendered correctly
   on the Mac with other applications, e.g., NeoOffice.

2) I have a mighty mouse(?) and Cocoa Emacs doesn't seem to register a click
   from the mouse-2 (the scroll ball) although it does scroll if I roll the
   ball.

3) Using M-x gdb with gdb-many-values set to t, the associated buffers, e.g.,
   stack locals etc. have an extra ^M at the end of each line.  What change
   should I make to gdb-ui.el to get rid of this?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Cocoa Emacs

[Nick Roberts]

I've configured with "configure --with-ns" and Emacs expects to find the DOC
file somewhere _like_ ~/emacs/nextstep/Emacs.App/resources/Content/etc but
every time I do make it's put in ~/emacs/etc and I have to move it manually.

Do I need to do something else?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Cocoa Emacs

[Adrian Robert]

> ... Emacs expects to find the DOC
...

"make install"

Re: Cocoa Emacs

[Nick Roberts]

Adrian Robert writes:
 > 
 > > ... Emacs expects to find the DOC
 > ...
 > 
 > "make install"

OK, thanks.  I did briefly consider (but not try) this but assumed that, by
default, "install" would put Emacs somewhere common like /Applications, not in
a directory in my personal workspace.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Cocoa Emacs

[David Reitter]

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

On 21 Aug 2008, at 21:59, Adrian Robert wrote:

>
>> ... Emacs expects to find the DOC
> ...
>
> "make install"

"make" seems to update the binary within nextstep/Emacs.app, but also  
increases the version number, which is why the new DOC is expected.
It would be sensible to leave Emacs.app in a consistent state, either  
way, i.e. produce the new DOC and (!!) delete the previous DOC.



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

Re: Cocoa Emacs

[Adrian Robert]

On Aug 22, 2008, at 7:39 AM, David Reitter wrote:

> On 21 Aug 2008, at 21:59, Adrian Robert wrote:
>
>>
>>> ... Emacs expects to find the DOC
>> ...
>>
>> "make install"
>
> "make" seems to update the binary within nextstep/Emacs.app, but  
> also increases the version number, which is why the new DOC is  
> expected.
> It would be sensible to leave Emacs.app in a consistent state,  
> either way, i.e. produce the new DOC and (!!) delete the previous DOC.

I've always found this version number increase puzzling and annoying,  
but imagine it has some purpose.  My current solution is to run a  
script like this whenever I want to rebuild:

#!/bin/sh
rm -f ../etc/DOC-* emacs-*
make -j3

If anyone wants to try to amend the Emacs.app build process to do  
something less hackish I heartily welcome the effort.

Re: Cocoa Emacs

[Adrian Robert]

On Aug 22, 2008, at 5:06 AM, Nick Roberts wrote:

> Adrian Robert writes:
>>
>>> ... Emacs expects to find the DOC
>> ...
>>
>> "make install"
>
> OK, thanks.  I did briefly consider (but not try) this but assumed  
> that, by
> default, "install" would put Emacs somewhere common like / 
> Applications, not in
> a directory in my personal workspace.

Some message text is output at the end of "configure" detailing what  
will happen.

It would make sense to have "install" should behave as you suggest,  
however it's also nice to be able to test a newly built Emacs.app  
"nondestructively", and the only way to get everything assembled so  
this will work is to use make procedures under the "install" target to  
do the packaging.

A way to get the best of both worlds would be to add an ns-appdir  
configure option which defaults to ./nextstep but could be set to,  
e.g., /Applications.  Such an option was there before, but I took it  
out during the process of simplifying the build and getting rid of the  
extra compile script we used to have.  Perhaps now would be a good  
time to add it back in though.

(Note, if you pass --disable-ns-self-contained, the lisp and other  
files will be installed in a common location, but the app still goes  
under nextstep/.)

Re: Cocoa Emacs

[Nick Roberts]

 > A way to get the best of both worlds would be to add an ns-appdir  
 > configure option which defaults to ./nextstep but could be set to,  
 > e.g., /Applications.  Such an option was there before, but I took it  
 > out during the process of simplifying the build and getting rid of the  
 > extra compile script we used to have.  Perhaps now would be a good  
 > time to add it back in though.

Doesn't 

configure --exec-prefix=/Applications

do this?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Cocoa Emacs

[Adrian Robert]

On Aug 22, 2008, at 5:31 PM, Nick Roberts wrote:

>> A way to get the best of both worlds would be to add an ns-appdir
>> configure option which defaults to ./nextstep but could be set to,
>> e.g., /Applications.  Such an option was there before, but I took it
>> out during the process of simplifying the build and getting rid of  
>> the
>> extra compile script we used to have.  Perhaps now would be a good
>> time to add it back in though.
>
> Doesn't
>
> configure --exec-prefix=/Applications
>
> do this?

Does it?  Exec-prefix has a different meaning (where do bare binaries  
go, not an application package), which is why the Carbon port and I  
propose the NS one as well use a distinct "appdir" config option.

Re: Cocoa Emacs

[Nick Roberts]

 > > Doesn't
 > >
 > > configure --exec-prefix=/Applications
 > >
 > > do this?
 > 
 > Does it?  Exec-prefix has a different meaning (where do bare binaries  
 > go, not an application package), which is why the Carbon port and I  
 > propose the NS one as well use a distinct "appdir" config option.

Perhaps I mean 

configure --prefix=/Applications

I'm just thinking that /Applications/somewhere should correspond to /usr/local.
I'm not a config expert and don't really understand why MacOSX needs wrappers
for applications.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Cocoa Emacs

[Lynbech Christian]

It used to be that the following configure option would enable
installation to /Application:

  --enable-carbon-app[=DIR]
                          specify install directory for Emacs.app on Mac OS X
                          [DIR=/Application]

but it no longer is so. Now installation goes to ./ns (I think, I am not
close to my mac) inside of the emacs source directory. The chance
happened when the cocoa branch was merged in (possibly it is just that
the cocoa branch did not take that carbon functionality with it).

It is actually rather usefull (if a bit out of line with the other
architectures) since it makes it easy to test out the compiled result
without wrecking an existing installation in /Application and it is
anyway easy to do the proper "installation", just move the .app
directory to /Application.


------------------------+-----------------------------------------------------
Christian Lynbech       | christian #\@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
                                        - petonic@hal.com (Michael A. Petonic)

Re: Cocoa Emacs

[Stefan Monnier]

>> ... Emacs expects to find the DOC
> ...
> "make install"

What would be ood would be to allow "run in place" as is done for X11.
E.g. I basically *never* do "make install", I always just do "make" and
then run src/emacs.  Some of the reason why this is good is that C-h
f and C-h v allow you to jump to the checked out source code from which
you built the code, rather than some copy of it.


        Stefan

Re: Cocoa Emacs

[Adrian Robert]

On Aug 28, 2008, at 3:29 PM, Stefan Monnier wrote:

>>> ... Emacs expects to find the DOC
>> ...
>> "make install"
>
> What would be ood would be to allow "run in place" as is done for X11.
> E.g. I basically *never* do "make install", I always just do "make"  
> and
> then run src/emacs.  Some of the reason why this is good is that C-h
> f and C-h v allow you to jump to the checked out source code from  
> which
> you built the code, rather than some copy of it.


Running an NS application in GUI mode requires the .app bundle  
structure.  So running straight out of src/emacs could not work.  But  
right now basic .app bundle, sans support binaries, is mostly  
assembled (under nextstep/) by plain "make".  Some load-path jockeying  
could probably get this to run without "make install", but care would  
need to be taken to do this compatibly with both shared-lisp and self- 
contained final installs.

Re: Cocoa Emacs

[Stephen J. Turnbull]

Adrian Robert writes:

 > Running an NS application in GUI mode requires the .app bundle  
 > structure.

But aren't app bundles relocatable?  So isn't the logical thing to do
to have make's default target make the full app bundle?  And perhaps
rename src/emacs to something like src/a-working-emacs-but-you-\
probably-want-the-one-somewhere-under-dotdot-slash-nextstep.