Emacs and Leopard problems continue

[Mark Evenson]

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.

Mac OS X 10.5 Leopard's /usr/bin/emacs is not linked to X11:  it will 
only work within a Terminal.app, an xterm, or anything that supports a 
termcap entry (you can verify this via "otool -L /usr/bin/emacs" which 
shows that it is not linked against X11 libaries).

Personally, I like using the X11 version under OS X to give consistency 
to my emacs experience across UNIX/Max OS X development.  And I never 
really totally understand the need to "Carbonize" or "Aquaify" the port, 
although Cut and Paste with the Mac OS X clipboard sometimes acts a 
little wonky (tip:  use the Emacs menu item for Paste when CMD-v fails 
to insert properly).  But maybe the cute Emacs icon has something to do 
with it, like being able to switch via the OS X switcher (and the 
'emacs-app' port icon is even better!)

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

I have submitted a patch [1] to the current ticket within MacPorts Trac, 
and am trying to get it promoted through to commit to the tree (I am a 
maintainer for some MacPorts, although not editors/emacs, but do not 
have commit rights.)

I agree that the response time on fixing this has been "lame", but 
calling the port "lame" is a trifle over the top, don't you think?  Not 
a great way to win friends and influence people. . .

[1]: http://trac.macports.org/projects/macports/ticket/13942

Some instructions for using my patch for those who are following from 
the sidelines:

1. Pick a spot to build the port, like

     osx$ mkdir ~/ports

2. Copy the existing emacs build infrastructure over:

     osx$ cp -pr `port dir emacs` ~/ports

3. Replace the existing 'Portfile' with my [trivially patch][2]:

[2]: 
http://trac.macports.org/projects/macports/attachment/ticket/13942/emacs-Portfile.diff

     osx$ cd ~/ports/emacs
     osx$ wget 
http://trac.macports.org/projects/macports/attachment/ticket/13942/emacs-Portfile.diff
     osx$ patch -p0 < emacs-Portfile.diff

4. Add the [upstream emacs patch to the files directory][3]

[3]: 
http://trac.macports.org/projects/macports/attachment/ticket/13942/patch-src-unexmacosx.c

     osx$ cd ~/ports/emacs/files
     osx$ wget 
http://trac.macports.org/projects/macports/attachment/ticket/13942/patch-src-unexmacosx.c

5.  Build and install:

     osx$ cd ~/ports/emacs
     osx$ sudo port -D . install

When the official Portfile gets updated, this change will be 
automatically overridden by a normal 'port upgrade outdated' procedure.

-- 
<Mark.Evenson at gmx.at>

"[T]his is not a disentanglement from, but a progressive knotting into."



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


-- 
<Mark.Evenson at gmx.at>

"[T]his is not a disentanglement from, but a progressive knotting into."