Emacs and Leopard problems continue

[Rob MacLeod]

Mark,

I totally agree about the desirability of an X11 port for its look and  
feel.  I have tried all the Carbon and Aqua ports I have come across  
and none of them are superior (and most inferior) to the tried and true.

Thanks for the patch.  I will try it out and report any problems.  As  
for your semantics suggestion, anything that works worse with a new  
version than it did with the old is lame in my books (-:  That does  
not mean the people who write and maintain it are lame.  They are my  
heroes!!  Still looking forward to the new and improved X11 that will  
eventually catch up to the one we had under 3 months ago under Tiger;  
it's hard to have to go through the evolution once again....  but that  
is an not a MacPorts problem.  (-:

Cheers,
Rob


On Feb 4, 2008, at 8:07 AM, Mark Evenson wrote:

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