Emacs on MAC OS X 10.3

Emacs on MAC OS X 10.3

[Dusan Turk]

Dear Emacs developers,

I've downloaded the latest emacs 21.3.50.1 binary for MAC OS X 10.3. And 
almost none of the font changes works.  I am used to work with emacs 
invoking it by the following command on a variety of X11 based platforms:

emacs -ms yellow -cr yellow -bg black -fg green -fn 
-misc-fixed-medium-r-normal--20-140-100-100-c-100-iso8859-1

By buying a Powerbook I would like to do the same.  The problem is that 
whatever font I try to set via the menu I get "Font not found".  With 
M-x set-frame-font - the lucida type seems to work and some other 
unuseful onse as well.

The font I want to use does exist (xfontsel, xlsfonts) find it.  Also 
xterm does recognize it and applies it.  So I assume that it is a bug in 
the Emacs distribution.  Would be great if it worked.

best regards,

dusan turk


-- 
********************************************************************
Dusan Turk                           e-mail: dusan.turk@ijs.si
Dept. of Biochem. and Mol. Biol.     phone: +386 1 477 3857 
Jozef Stefan Institute               fax: +386 1 257 3594
Jamova 39, 1 000 Ljubljana
Slovenia, (EUROPE)
********************************************************************

Re: Emacs on MAC OS X 10.3

[Benjamin Riefenstahl]

Hi Dusan,


Dusan Turk <Dusan.Turk@siol.net> writes:
> I've downloaded the latest emacs 21.3.50.1 binary for MAC OS X
> 10.3. [...] 
>
> [...] The problem is that whatever font I try to set via the menu I
> get "Font not found".  [...] 

> The font I want to use does exist (xfontsel, xlsfonts) find it.

These are X11 utilities.  They report information about the separate
X11 environment, which will does things differently from the rest of
the system and from non-X11 programs.

As you are already using X11, you may have more success with using an
X11 Emacs instead of an Aqua Emacs.  There is a Fink package for that
<http://fink.sourceforge.net/pdb/package.php/emacs>. 

> Also xterm does recognize it and applies it.  So I assume that it is
> a bug in the Emacs distribution.  Would be great if it worked.

Sadly, there is no maintainer for the Aqua Emacs at the moment. 


benny

Re: Emacs on MAC OS X 10.3

[Ted Lemon]

On Dec 17, 2003, at 4:56 AM, Benjamin Riefenstahl wrote:
> Sadly, there is no maintainer for the Aqua Emacs at the moment.

I volunteered to do it, but what with all the savannah hassles, I think 
that's fallen into a black hole.   However, it's not really Aqua emacs 
- it's Carbon emacs.   There are a lot of stubs in the carbon module 
(macterm.c) that need to be filled in, and that might help out a bit, 
but it would be quite a challenge to make it work with X-style font 
names, because the font names in Carbon are the Mac font names, not the 
X font names.

I'd actually like to add an experimental set of Aqua stubs, although 
given that the Carbon code is quite stable now and also works on MacOS 
9, I don't think it's time to switch to Aqua yet.

Consolidation of image support (was Re: Emacs on MAC OS X 10.3)

[Kim F. Storm]

Ted Lemon <mellon@fugue.com> writes:

> On Dec 17, 2003, at 4:56 AM, Benjamin Riefenstahl wrote:
> > Sadly, there is no maintainer for the Aqua Emacs at the moment.
> 
> I volunteered to do it, but what with all the savannah hassles, I
> think that's fallen into a black hole.   However, it's not really Aqua
> emacs - it's Carbon emacs.   There are a lot of stubs in the carbon
> module (macterm.c) that need to be filled in, and that might help out
> a bit, but it would be quite a challenge to make it work with X-style
> font names, because the font names in Carbon are the Mac font names,
> not the X font names.
> 
> I'd actually like to add an experimental set of Aqua stubs, although
> given that the Carbon code is quite stable now and also works on MacOS
> 9, I don't think it's time to switch to Aqua yet.
 
Be aware that I plan (in the near future) to take out the image
support code from xfns.c, w32fns.c and macfns.c and consolidate it in
a new image.c file.  

That should reduce 15000 lines of code to approx 5500 lines.

It seems that most of the image code in macfns.c isn't actually
used/ported yet, so it would be a good thing to consolidate the code
before finishing the image support for MAC.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Emacs on MAC OS X 10.3

[Benjamin Riefenstahl]

Hi Ted,


> On Dec 17, 2003, at 4:56 AM, Benjamin Riefenstahl wrote:
>> Sadly, there is no maintainer for the Aqua Emacs at the moment.

Ted Lemon <mellon@fugue.com> writes:
> I volunteered to do it,

Cool, that's great!

> However, it's not really Aqua emacs - it's Carbon emacs.

I thought that Aqua is the whole GUI system and/or look-and-feel and
Carbon and Cocoa are the APIs?

> I'd actually like to add an experimental set of Aqua stubs, although
> given that the Carbon code is quite stable now and also works on
> MacOS 9, I don't think it's time to switch to Aqua yet.

I think that there once was a NextSTEP port of Emacs, right?  But I
guess very little of that code is still usefull today for a recent
Emacs version.


benny

Re: Consolidation of image support (was Re: Emacs on MAC OS X 10.3)

[YAMAMOTO Mitsuharu]

>>>>> On 18 Dec 2003 01:53:20 +0100, Kim F. Storm said:

> Be aware that I plan (in the near future) to take out the image
> support code from xfns.c, w32fns.c and macfns.c and consolidate it in
> a new image.c file.  
> 
> That should reduce 15000 lines of code to approx 5500 lines.
> 
> It seems that most of the image code in macfns.c isn't actually
> used/ported yet, so it would be a good thing to consolidate the code
> before finishing the image support for MAC.

Actually, I've been porting the image support code to Carbon Emacs,
and I think it's almost ready now although some features are not
implemented yet.  I was planning to send the patch as soon as my
assignment paper is accepted, and currently I'm waiting for the form
to be delivered to me.  Should I send the patch now?  Many parts in
macfns.c is almost identical with those in xfns.c.

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

Re: Emacs on MAC OS X 10.3

[Richard Stallman]

    I volunteered to do it, but what with all the savannah hassles, I think 
    that's fallen into a black hole.

We're hoping to have Savannah up again soon, but in the mean time,
you can still write the code, right?

Re: Emacs on MAC OS X 10.3

[Steven Tamm]

>> However, it's not really Aqua emacs - it's Carbon emacs.
> I thought that Aqua is the whole GUI system and/or look-and-feel and
> Carbon and Cocoa are the APIs?

There is a project called emacs-on-aqua that is based on the NeXTStep 
port.  There's a webpage for it here: 
http://emacs-on-aqua.sourceforge.net/   I think this is what is leading 
to the confusion.  That project was misnamed, and the webpage and the 
CVS tree do not appear to have been updated in over a year.

As far as terms, Quartz is the windowing/compositing system 
(technically the window manager); Aqua is the GUI (a marketing term); 
Carbon and Cocoa are APIs to write Aqua apps.

>> I'd actually like to add an experimental set of Aqua stubs, although
>> given that the Carbon code is quite stable now and also works on
>> MacOS 9, I don't think it's time to switch to Aqua yet.
>
> I think that there once was a NextSTEP port of Emacs, right?  But I
> guess very little of that code is still usefull today for a recent
> Emacs version.

When I first had OSX, I started using that "emacs on aqua" port, but 
found it easier to add my required functionality directly to the main 
trunk by migrating the event model from the legacy model to the Carbon 
model.

IMHO, there is little benefit that would be derived from switching from 
Carbon to Cocoa, but there really isn't a need to choose, since use of 
Carbon and Cocoa (i.e. ObjC) can be intermixed.   There is very little 
functionality that Cocoa exposes that Carbon doesn't, and that's mostly 
confined to the pasteboard.    However, the image APIs in Cocoa are a 
lot easier to use than the similar APIs in Carbon; so the big missing 
hole (mac/README) in the port might be easier to write in Cocoa.

-Steven

Re: Consolidation of image support (was Re: Emacs on MAC OS X 10.3)

[Kim F. Storm]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> >>>>> On 18 Dec 2003 01:53:20 +0100, Kim F. Storm said:
> 
> > Be aware that I plan (in the near future) to take out the image
> > support code from xfns.c, w32fns.c and macfns.c and consolidate it in
> > a new image.c file.  
> > 
> > That should reduce 15000 lines of code to approx 5500 lines.
> > 
> > It seems that most of the image code in macfns.c isn't actually
> > used/ported yet, so it would be a good thing to consolidate the code
> > before finishing the image support for MAC.
> 
> Actually, I've been porting the image support code to Carbon Emacs,

That will make MAC users happy I suppose :-)

> and I think it's almost ready now although some features are not
> implemented yet.  I was planning to send the patch as soon as my
> assignment paper is accepted, and currently I'm waiting for the form
> to be delivered to me.  Should I send the patch now?  

No need to do so.

I don't expect to actually work on the consolidation until CVS is back
up again.  I want to be sure to get any fixes to that people -- like
yourself -- may have laying around waiting to be committed before I
start.

>                                                       Many parts in
> macfns.c is almost identical with those in xfns.c.

I would have expected that (otherwise there would be no reason to
consolidate the code :-)


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Emacs on MAC OS X 10.3

[Kim F. Storm]

Steven Tamm <steventamm@mac.com> writes:

> IMHO, there is little benefit that would be derived from switching
> from Carbon to Cocoa, but there really isn't a need to choose, since
> use of Carbon and Cocoa (i.e. ObjC) can be intermixed.   There is very
> little functionality that Cocoa exposes that Carbon doesn't, and
> that's mostly confined to the pasteboard.    However, the image APIs
> in Cocoa are a lot easier to use than the similar APIs in Carbon; so
> the big missing hole (mac/README) in the port might be easier to write
> in Cocoa.

Well it seems that YAMAMOTO Mitsuharu has already done most of the
porting, so this would seem rather academic now.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk