A Comparison of Xemacs and Gnu Emacs
Precompiled binaries for Linux and many other operating systems are available from ftp://ftp.xEmacs.org and its mirrors. Generally there is a common file which everyone needs; this contains the platform-independent LISP files and miscellaneous documentation, a mix of the GNU Emacs documents and Xemacs-specific stuff. A smaller file contains the binaries for your platform. For Linux there is a choice between statically-linked Motif executables, dynamically-linked Motif executables (for those who own a copy of the the Motif libraries), and dynamically-linked Athena executables; the latter is probably the best choice if you don't have Motif.
If you want to compile your own executables, be prepared to make lots of disk space available. 70MB is a bare minimum (including the unpacked source code) that will work if you “compile in place”, i.e., the source-code directory will be where you leave Xemacs. This way the new executable refers to LISP files in the source directory. Otherwise you need another 50MB momentarily. The structure of the Xemacs directory tree is hard-coded into the executable; if you'd like to customise it the Makefile has paths that can be edited.
There are various reasons for compiling your own executable—perhaps you have no need of the icon toolbars. I've noticed that I rarely use them now that I'm more familiar with the equivalent keystrokes, and they do use memory you might not have to spare. The toolbar support (as well as the pop-up menu support) can be disabled at compile time, helping to create a leaner executable.
Another possible change is the inclusion of a frequently used package in the executable, rather than loading it separately from the ~/.Emacs initialization file.
Once you've unpacked the massive Xemacs archive files you may very well be dismayed by the amount of disk space they occupy. Luckily you can delete quite a bit of them and still have a great editor. If you look at the subdirectories under the LISP directory you will find many bulky packages for which you may never have a need, such as the Object-Oriented Browser and Hyperbole. If you have no desire to use Xemacs as a web browser (W3 is well-implemented but rather slow), the W3 and URL subdirectories can go. I recommend spending some time browsing through the LISP subdirectories; the un-byte-compiled *.el files are human-readable and most contain informative notes which will help you decide if you want to keep them or not. Another substantial amount of disk-space can be reclaimed by simply gzipping all of the *.el files; Xemacs doesn't need them at all. The reason that they are included with Xemacs is to give users the opportunity to edit them in order to modify their behaviour. The byte-compiled *.elc files are what Xemacs actually uses.
When either version of Emacs is started the program immediately checks your home directory for an .Emacs file. This LISP file tells Emacs which packages you would like loaded and can set a vast array of user choices. Xemacs comes with a sample.Emacs file (in the /etc subdirectory) that is well commented and includes several default functions which many have found useful. Even more useful is the version-detection code, which determines whether you are running Gnu Emacs or Xemacs and the version number. Separate sections of the file are read by corresponding versions of Emacs, allowing the use of the same .Emacs file for any version of Xemacs or Gnu Emacs.
This permits the user to have both Xemacs and Gnu Emacs installed and usable at the same time, allowing for comparison. Xemacs 19.14 refines this even further, putting its configuration in a separate file called ~/.xEmacs-options that is called from within the ~/.Emacs file.
Though the prospect of writing LISP code in order to introduce your own functions and modifications into your .Emacs file may seem daunting, learning by imitating what others have done can be effective as well. Another help is the detailed documentation supplied with both versions in the form of hierarchical Info files. Several skilled Emacs users have posted their personal ~.Emacs files on web pages; a search conducted with Lycos or Alta Vista for the keywords Emacs, Gnu Emacs, or Xemacs will easily find such pages.
Although at first exposure it may seem that Xemacs offers more to users, Gnu Emacs has certain features that will tip the scales in its favor for some people. If you have the GPM console mouse server installed (this is included in most distributions of Linux) Gnu Emacs interacts well with it, giving full mouse support in console mode. Xemacs has limited mouse functionality in a console session, but has the advantage of full face support in a console, i.e., syntax highlighting will work in a console session, although without as many colors as in an X session.
Gnu Emacs has a convenient editing feature: text copied or cut from a file can be accessed from a pull-down menu on the menu bar, with each piece of text identified by its first few words. While there is a way to implement a similar function in Xemacs, it's not documented in the distribution.
If memory usage is a factor for you, Gnu Emacs typically uses about 2MB less than Xemacs, and its startup time is slightly shorter. Of course, if you would like a lean, low-memory version of either Emacs, you can compile without X Window System support.
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.
Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.
Sponsored by ActiveState
| Speed Up Your Web Site with Varnish | Jun 19, 2013 |
| Non-Linux FOSS: libnotify, OS X Style | Jun 18, 2013 |
| Containers—Not Virtual Machines—Are the Future Cloud | Jun 17, 2013 |
| Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer | Jun 12, 2013 |
| Weechat, Irssi's Little Brother | Jun 11, 2013 |
| One Tail Just Isn't Enough | Jun 07, 2013 |
- Speed Up Your Web Site with Varnish
- Containers—Not Virtual Machines—Are the Future Cloud
- Linux Systems Administrator
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Non-Linux FOSS: libnotify, OS X Style
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- RSS Feeds
- Web & UI Developer (JavaScript & j Query)
- Reply to comment | Linux Journal
2 hours 15 min ago - Yeah, user namespaces are
3 hours 32 min ago - Cari Uang
7 hours 3 min ago - user namespaces
9 hours 56 min ago - yea
10 hours 22 min ago - One advantage with VMs
12 hours 51 min ago - about info
13 hours 24 min ago - info
13 hours 25 min ago - info
13 hours 26 min ago - info
13 hours 28 min ago
Featured Jobs
| Linux Systems Administrator | Houston and Austin, Texas | Host Gator |
| Senior Perl Developer | Austin, Texas | Host Gator |
| Technical Support Rep | Houston and Austin, Texas | Host Gator |
| UX Designer | Austin, Texas | Host Gator |
| Web & UI Developer (JavaScript & j Query) | Austin, Texas | Host Gator |
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?




Comments
nice comparison
but i lol'ed at 'lots of disk space' somehow meaning '50mb'... maybe 5 _thousand_ MB would be a lot... even then, just during compile I couldn not care less how much space is used