Slashdot Mirror
The Future of Emacs
An anonymous reader writes "If you've not heard much about Emacs development in recent years, you might
be surprised to find that it is has been very active. Emacs 22 will have many
new features such as support for Mac OS X and Cygwin; mouse wheel support
and many new modes and packages. It can also be built with Gtk+ widgets and
supports drag and drop for X. The NEWS file details all the changes.
Although its very stable, don't expect to see it released any time shortly because according to
RMS, the Emacs developers haven't been fixing bugs quickly enough. Those
who have followed Emacs for long enough might see a different pattern."
Since we're talking about Emacs here, it would be good to clarify whether Emacs will be running under OS X and Cygwin or the other way around.
I too have felt the cold finger of injustice.
mouse-wheel.el has been providing mouse wheel support for years. It's just being added to the core distribution.
Debian unstable has weekly snapshots of cvs emacs.- snapshot
http://packages.debian.org/unstable/editors/emacs
I have been using it for some time now and it works like a charm.
real men use ed
No, real men use cat, and get it right the first time!
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
Emacs and Vi have both been around for a very long time. Back in the mid-late 80's, I remember taking some computational math and fluid dynamics classes. Part of the projects involved writing FORTRAN code and the professors used Vi. As a result, documentation was readily available so, I used Vi as well. Of course, Emacs was there too but the documentation was not as available. Frankly, just shutting the command line version of Emacs down took some research. Anyway, there was a palpable elitism among the Emacs crowd which I always assumed to be more due to them using the "un-official" and more complex editor. As for myself, I didn't care, the editor was the means to the end, not the end in itself.
Nowadays, Emacs (and XEmacs) have nice GUI's in front of them that greatly simplify their use. I use XEmacs on my Windows box (through Cygwin) at work and Emacs on my Ubuntu and SuSE Linux boxen at home. I still use Vi (Vim nowadays) when I need to quickly pop into the command line and do a config file edit, but I program in (X)Emacs. I know there is some sort of friction between the Emacs and XEmacs camp but that's not my concern. I use them both and I like them both.
It's very bizarre that, 20 some odd years later, the Emacs/Vi war still rages on. For me, the editor is the means to the end and always will be. Heck, with Ubuntu, I'm starting to use gedit more and more.
A goal is a dream with a deadline
Have you ever been writing a document then suddenly thought "Gee I'd love to play chess at the moment"? With another editor you'd be stuffed - you'd probably have to open another program or something, but not with Emacs.
With Emacs you could be editing your document while chatting on IRC and checking your email, and you wouldn't even need another program. I heard with the new version it will make you tea and give you a massage. I know it already comes with a kitchen sink: apt says so.
I don't see any line item bugs for "Make Emacs like Eclipse". There should be.
Eclipse kills emacs. Emacs will be relegated to a super niche market if it does not borrow some of the techniques of Eclipse.
Eclipse has many more than the following advantages:
Programming domain issues have been thought out. Code gen follows some patterns, and eclipse makes far better use of them that emacs
-- Such advantages as click on a variable to go to its instantiation.
-- Underlining errors
-- sure you CAN spend hours trawling for the modules to do the same for emacs, but that sucks, and yields variable results.
A unified project space is opened up by default. You can see all your files.
-- It takes a while to work out where Speedbar is under emacs and it sucks. Even if it sucks it should be opened by default, like *scratch*
I'm happy to use Emacs everyday. But the reason I use it is:
I finally have a .emacs I'm happy with
You can run it well over ssh
It has emacs keybindings [duh, but important]
These are not enough reasons to bring new emacs users into the project. What do we do if RMS is hit by a bus or the existing emacsers eventually die of old age? Emacs people need to form and take ownership of sub projects around certain problem domains. e.g. Go HERE for Perl Emacs and HERE for XML editing. At the moment all you have is a loose coalition of Perl.com et alia articles.
[% slash_sig_val.text %]
The only other editors I'd consider would be Vim (because if Emacs is lightweight by today's standards, Vim is even lighter -- but then, there's also Zile), and JEdit (because it is the only one that comes close in functionality).
You know, I'm a fan of emacs, but doesn't this everything-and-the-kitchen-sink approach go against the Unix philosophy of making lots of small interoperable tools that do one thing really well?
But you see, that is why emacs is so great, because all of these 'features' are not 'built into' emacs, but in fact emacs lisp programs that extend the basic editing functionality. The core emacs abilities are key to editing: supply a place for the text to be displayed (buffers), supply easy ways to switch between multiple files being edited (this may be slight overkill -- perhaps a window manager should be used for this, or some terminal switching type program, but getting the kill ring to come across those would be hard), supply a good arsenal of editing commands at a low level, and supply the ability to change the action mapped to any key. All the rest is on top of this core. A lot of the functionality is even sourced from other commands (like ediff -- uses diff).
I think it was Eric Raymond who said that all the time that went into snazzy interfaces and GUI support in other programs was spent on editing text in emacs. It shows -- if you want to edit text, use a dedicated text editor.
That being said, I think the main reason for Tetris in emacs is "because it's there" -- on some geek level it seems quite cool to me.
Languages aren't inherently fast -- implementations are efficient
Despite the trollish title of this post, I'm essentially an emacs fan. I am a writer, not a coder, and prefer the command line over GUI. I am the author of the Woodnotes Guide to Emacs for Writers (HTML) (PDF Version) and a bunch of books and papers..
But I find myself using emacs less and less frequently. My first complaint is getting emacs and my Linux console to work correctly with diacritical marks. I know that's a function not only of emacs but also the packagers of my distribution, plus a deplorable lack of easily-installed console fonts that contain those glyphs. But regardless of whose fault it is, this problem makes it hard for me to get my work done the way I want to.
I also need to program lots of small macros for very specific text editing features while writing a book that requires a silly markup format unique to the industry. Emacs was simply too hard to program for me to be able to implement it. Instead, I found Jedit, which easily facilitated things like switching between soft and hard wrap, keystroke macros, and some features I now find indispensable, like search and replace across all documents in a directory.
It's not that emacs doesn't or can't implement these features, it's that it doesn't do so easily. I wrote up a little page about the macros and jedit features I use most frequently. It would be extremely difficult to publish similar instructions for emacs because of the greater difficult inherent in installing, using, and sharing macros.
I still use emacs, but I use it for emailing, in conjunction with Mutt, the world's best email client. And for writing, I tend to stick to Jedit. Best of luck to emacs, which I still like, but I think for people like me the world has progressed and emacs is of limited use.
If this were Usenet, I'd killfile the lot of you.
I should start off by saying that up until very recently, Emacs has been my main editor. I work on Mac OS X and Linux primarily, and have used Emacs for quite some time. Emacs has worked on OS X for awhile already (either under the Carbon variants that exist, or via X, or via the terminal), so in that regard the article is somewhat misleading.
What I like most about Emacs is that it has the best support for non-mainstream programming languages of any editor, ever. Period. I program in more than a dozen languages (C, C++, Java, Haskell, OCaml, SML, AliceML, Oz, Erlang, Scala, Scheme, Common LISP, Python, Perl, Ruby, APL, etc.), and many of those languages either have no support in other editors, or very poor support if they do. Emacs is the only editor that has at least *decent* support for all of them, and in a way that allows me to maintain a fairly similar style of usage across different languages. In other words, I get to keep my basic functionality and editor customizations relatively the straightforward and things just work pretty well no matter what task I am currently doing. On top of that, extending Emacs functionality to make certain tasks easier is pretty simple, even if you don't know much in the way of elisp. Most of the time, you can simply dig up a snippet of functionality off emacswiki.org. But adding stuff yourself isn't difficult, and the ability to evaluate elisp code inside of emacs itself speeds up the process of writing more complex functionality.
However, it's not all roses. Despite the power of emacs, the reality is that emacs is arcane and outdated as hell. The ugliest manifestations of this arrive in a few different ways:
1) One of them is the ad-hoc way in which emacs is customizable. Emacs basically just runs elisp scripts at run time, and whatever sort of state changing computations that are contained in those scripts reflect themselves in the editor you are eventually presented with. This is a fine idea on a small scale. On a large scale, it's bad. For one thing, it makes extending the editor in specific fashions, with complex features, much more difficult to do in a maintainable way. Essentially, there's little in the way of structure to help maintain conceptual integrity here. It's easy for things to break when you start to combine complex functionality from different pieces of code (usually manifested as modes or something similar) in ways not forseen by their respective authors beforehand. The other end of this, which falls in line with the maintainability problem, is the fact that this approach makes code reuse more difficult. Extensions to the editor in the form of elisp scripts are usually a one-off affair, and are not typically made to be particularly modular. You see the result of this in major-modes which largely accomplish the same tasks, but never share any of the same code. This is common not only in the modes for different programming languages (say they might all support a REPL, but in a slightly different way), but also with modes for other purposes.
2) Unicode support. Emacs is getting much better here in more recent times, but it's far from perfect. Unicode support is difficult to setup on Emacs in a way that is easy to use and works predictably. I have had more experience here on Mac OS X with emacs, so admittedly it's possible that the situation isn't as bad on other platforms. However, true, well integrated Unicode has been late in coming to Emacs because of the legacy of design in the way Emacs has traditionally handled text manipulation and fonts.
3) Display. Emacs text display is starting to show its age. I don't pretend to understand exactly how text display and font handling works in Emacs, but I understand that it is based on legacy designs. Manipulation of the display in text through emacs, with stuff like region highlighting or font locking, is nowhere near as flexible as what is possible in text views for editors in more modern frameworks that follow a design more akin to presentation through styles (
"Although its very stable, don't expect to see it released any time shortly because according to RMS, the Emacs developers haven't been fixing bugs quickly enough."
Yeah, it's really too bad they don't work quite as fast as those Hurd guys.
#DeleteChrome