Emacs and Leopard problems continue

[Jordan K. Hubbard]

On Feb 4, 2008, at 5:46 AM, Rob MacLeod wrote:

> I was not able to get the Leopard shipped version of emacs to fire  
> up an X window.    All it would do was drive the terminal window (or  
> X11 xterm) from which I launched it.  This is not acceptable, of  
> course.

The leopard shipped emacs is linked with Carbon.  You don't NEED X for  
that version if you use the app wrapper I sent out - it supports the  
NATIVE window system.

And if you prefer X11 to the native window system, well, it's just  
possible that you might be happier installing Linux or *BSD on your  
machine.

- Jordan

>
>
> I was able to download the generic emacs from the gnu site, apply  
> the patch that I got from the Macports edition of emacs, and then  
> get it to both build and work.  So why is the version on MacPorts  
> still so lame?  Is there someone maintaining this package?
>
> Cheers,
> Rob
>
> On Feb 4, 2008, at 6:19 AM, Mark Evenson wrote:
>
>> Jordan K. Hubbard wrote:
>>> OK, I'll bite.  What specifically is wrong with the system emacs  
>>> that requires folks to struggle so hard to build another copy?    
>>> It even supports carbon if you add an app wrapper (like the one I  
>>> just attached - a mere 55k, and most of that is the icon), so I'm  
>>> not sure what would lead one to struggle so hard to build emacs  
>>> again.   Yes, the macports version should certainly work just on  
>>> general principle, but that's not the question I'm asking.
>>
>> I was going to reply that /usr/bin/emacs is only emacs-21, but then  
>> I just noticed that Mac OS X 10.5 Leopard apparently ships with  
>> emacs-22.  Still, having the latest stable Emacs is a plausible  
>> desire for users still with Mac OS X 10.4 Tiger.
>>
>> A second plausible use case might be to use MacPorts for the  
>> packaging of various Emacs-modes (SLIME, nxml-mode, haskell-mode,  
>> etc.), offering an infrastructure for their timely updating.
>>
>>
>> -- 
>> <Mark.Evenson at gmx.at>
>>
>> "[T]his is not a disentanglement from, but a progressive knotting  
>> into."
>>
>