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.
--
<[EMAIL PROTECTED]>
"[T]his is not a disentanglement from, but a progressive knotting
into."
_______________________________________________
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users
