3 p.m.
> o What next? Gotta get mule in there, I guess. Where do I get
it,
> and where in the source hierarchy does it fall? I don't know that
> no mule is the only problem.
I went through this exercise last week... the first step is to add
"--with-mule" to the "configure" options. You may have to hunt down
&
install "gettext" and "iconv" as well; I had to, but I don't use
macports
(or any equivalent).
Aha! Okay. That allowed me to get all the way to the end and produces
a runnable xemacs.
I did make install under sudo, and it dropped stuff in /usr/local/lib and
in /usr/local/share, but nothing I recognize as a usable binary. There
is one in the src directory, though.
The one major headache that's always bothered me with xemacs is
where all the directories of stuff belong.
When I run the xemacs in this src directory, naturally it finds errors in
my ~/.xemacs/init.el, but that's got to be because it doesn't know where
to find the packages.
I ended up with an XEmacs image that appears to have no support for
the
native Mac Windowing system, and not X11 support. I'm pretty sure that it
should be possible to get the X11 support in there ...
Ummm. I've never heard of it running native on the Mac, and have always
assumed that X11 is required. I do have that. Since I first started using
Macs as a base of operations things have shifted around with X11, and
when I was configuring my iMac for use, I was told that this is now
under the auspicies of a organization (?) called XQuartz. In any case,
it was not difficult to install this, and in fact X11 now runs much better
than it ever did before.
Isn't X11 what the "X" in XEmacs is all about? Emacs that runs under
X11 in order to get graphics support? I always thought so.
Well, at least I got it to compile. Sometime RSN I'll have to tread my
way through the splatter that got left behind to see if I can get it to
actually work for me.
My days of testing stuff are long behind me. I've become the sort of guy
who just wants stuff on my own workhorse system to just work right,
with minimum hassles.
Thanks.
--
Lynn David Newton
Columbus, Ohio
neologisticsediting.com
lynndavidnewton.com
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:06 p.m.
New subject: compiling the beta on an iMac
>>>> "Lynn" == Lynn David Newton
<lynn.newton(a)gmail.com> writes:
>> o What next? Gotta get mule in there, I guess. Where do I
get
>> it,
>> and where in the source hierarchy does it fall? I don't know
>> that no mule is the only problem.
> I went through this exercise last week... the first step is to
> add "--with-mule" to the "configure" options. You may have to
> hunt down & install "gettext" and "iconv" as well; I had to,
> but I don't use macports (or any equivalent).
Lynn> Aha! Okay. That allowed me to get all the way to the end and
Lynn> produces a runnable xemacs.
Lynn> I did make install under sudo, and it dropped stuff in
Lynn> /usr/local/lib and in /usr/local/share, but nothing I
Lynn> recognize as a usable binary. There is one in the src
Lynn> directory, though.
Isn't there a /usr/local/bin/xemacs (that's symlinked to
xemacs-21.5-bxx)?
> I ended up with an XEmacs image that appears to have no support
> for the native Mac Windowing system, and not X11 support. I'm
> pretty sure that it should be possible to get the X11 support
> in there ...
Lynn> Ummm. I've never heard of it running native on the Mac, and
Lynn> have always assumed that X11 is required. I do have
There was a version that used Cocoa (Carbon?). I don't think that was
ever merged to xemacs.
Lynn> My days of testing stuff are long behind me. I've become the
Lynn> sort of guy who just wants stuff on my own workhorse system
Lynn> to just work right, with minimum hassles.
I'm in the same boat. I just want (most) things to work now.
Ray
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
1:59 a.m.
New subject: compiling the beta on an iMac
Lynn David Newton writes:
I did make install under sudo, and it dropped stuff in
/usr/local/lib and in /usr/local/share, but nothing I recognize as
a usable binary. There is one in the src directory, though.
There should be several new binaries in /usr/local/bin, too. No?
That would be a bug in the installation scripts.
The one major headache that's always bothered me with xemacs is
where all the directories of stuff belong.
One way to deal with this is to use something like "configure
--prefix=/opt/xemacs" so that everything XEmacs-y ends up under
/opt/xemacs, and nothing else does.
Ummm. I've never heard of it running native on the Mac,
There are two old ports that do so using the "Carbon" toolkit, but
neither was ever integrated into mainline. The xemacs-carbon branch
in the Mercurial repository was pretty good, but suffered from ethical
issues (the original author was a pigheaded legal moron, and objected
to changes in the permissions and copyright information required by
the GPL).
Between that enthusiasm-killer and the growing sense that GUI apps on
Mac needed to use the Cocoa toolkit, I lost heart for the xemacs-carbon
project, and nobody else ever picked it up (more precisely, Aidan
Kehoe did quite a bit of work on it, but didn't push for integration).
Isn't X11 what the "X" in XEmacs is all about?
Nope. It's a variable that stands for "Sun" or "Lucid",
depending. :-)
XEmacs has a long history of supporting non-X11/Xt UIs: Windows, GTK,
Qt, Mac, TTYs in the same instance as GUIs, BeOS (now Haiku). Some
are integrated, some aren't.
My days of testing stuff are long behind me. I've become the
sort
of guy who just wants stuff on my own workhorse system to just work
right, with minimum hassles.
I know what you mean. Heck, even Steve Baur said that XEmacs 21.1 was
his ideal editor, and lost a lot of interest in working on XEmacs once
21.4 was released.
However, XEmacs 21.4 is a dead letter, and if XEmacs continues to be
developed at all, new features will be available only in 21.5 and its
successors, including in the packages. We currently insist that
packages actually work on 21.4 so far as 21.4 provides their required
functionality, and fail gracefully if that is unavailable. This
policy won't change for at least a year, but is likely to change
within two years.
If XEmacs 21.4 serves all your needs, and you don't feel any need for
any of the "new stuff", great! you can ignore the above. You might
also want to look into the SXEmacs fork based on XEmacs 21.4 at
www.sxemacs.org, as long as you don't need Windows support. They've
got a lot of sexy features like an extended numerical tower and
foreign function support, some of which are already in XEmacs 21.5 and
others will probably get into 21.5 fairly soon. But they'll stay
ahead on such features for quite a while, I think. SXEmacs uses our
package repository. (This might mean we will not de-support 21.4 in
the packages for a long time, but they may prefer to sync necessary
features if they haven't done so already.)
However, the next release of XEmacs will definitely include much
better Unicode support (which is not just about foreign languages, but
also math symbols and extended punctuation, etc). It will probably
include features that make it a lot more useful for accessing
networked resources (improved TRAMP, WebDAV support, etc). It may
include native support for the Mac GUI (via Cocoa) and possibly Haiku.
If you're looking to do more with less work from XEmacs, you may want
to move to 21.5. YMMV....
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4329
days inactive
4330
days old
2 comments
3 participants
participants (3)
-
Lynn David Newton -
Raymond Toy -
Stephen J. Turnbull