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."
fast as fast can be. you'll never catch me.
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.
It's no wonder so many open source projects never make it as far as a v1 release - emacs is stealing all of the version numbers!
22!!
Emacs 22 will have many new features such as support for Mac OS X and Cygwin
Wait, so I can use my Emacs operating system on top my Windows operating system?
I'm still waiting for them to release an emacs that runs on the metal, without an inferior (read: not written in lisp) OS in the middle.
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.
Even though emacs is a very good editor and development platform that for a long time have filled the purpose of being a swiss army knife for the software developer, I think its days of glory are over.
Sure there will be emacs for many years to come, but I guess that Eclipse will more and more play that role for the generation of developers that grew up with graphical user interfaces. More and more programming languages gets supported by Eclipse, and the support of the existing ones seam to get better and better, and the community around it are getting stronger and stronger.
Even so, its nice to see that old goodies like emacs are still supported and continue to evolve.
God is REAL! Unless explicitly declared INTEGER
What's so great about it that people insist on using it rather than any other editor? Seems all of the features are available for just about any other editor, and most of themare a lot easier to configure, and more compliant with UI guidelines.
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."
The main problem I see with Emacs is its terrible learning curve. Given the competing IDEs now available, I can't see any future for it unless it radicaly simplify the process needed to master the program. Drag'n'drop and mouse wheel support? That's not enough - I'd even say that they're against the traditional Emacs keyboard-only workflow.
The only future I can see to the Emacs style of working is in projects like Archy or Quicksilver, which completely redefine the particular tasks while keeping its strengths.
Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
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
I never will understand people that use Emacs. If I wanted a bloated editor I'd be using Microsoft Word to edit my text files. When I want to edit a text file vi is infinitely easier, virtually universal on UNIX platforms, and has a tiny memory footprint.
Emacs is not (mainly) a text editor, it's an IDE for integrating the whole programming process.
Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
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 %]
Are you sure that shouldn't be mouse-whe.el?
Vi is a lot different from emacs. I use vi when I have to modify faster a configuration file from shell but I need emacs when I want to do something more complex. In my opinion the "war" between vi and emacs is a stupid thing. They are both good free software products, choose the one you like more, I like how emacs can be customized and improved with its emacs-lisp and I like vi when I have to edit a simple file. If you want the GTK version of emacs you can compile it by yourself, this is what I did.
was always "vi or emacs?" Since I was interviewing Unix developers, the answer could tell me a lot about them. The people with blank looks who didn't even know you were talking about editor were never asked back.
Genius is one percent inspiration and 99 percent perspiration, which is why engineers sometimes smell really bad.
The headline makes it sound like Emacs is in some kind of danger. I think it's probably one of the programs with the least likelihood of going away, ever; almost everybody who uses it is qualified to maintain it and reluctant to stop using it. Emacs will be around as long as keyboards.
I still won't use it, but it'll be around.
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.
Bugs aren't sinister things that magically creep into software when you aren't looking. With software that has been stable for a long time, such as EMACS, you can generally substitute the phrase "introducing bugs" where you see the phrase "discovering bugs".
The complaint isn't that there's some kind of deadline that the bug stompers have been ignoring, it's that people are working on new features instead of fixing the problems they already have. Which seems like a fairly reasonable thing to point out.
The whole Slashdot story can basically be summed up as "RMS says: You've been adding bugs - now go fix them!" Which is what any maintainer has to do from time to time, but I'm sure the Slashdot hordes are going to have a field day flaming him for it.
Bogtha Bogtha Bogtha
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 (
EMACS used to stand for Editor Macros.
Because when it was first released (by the end of the 70s), EMACS was in fact a TECO macros package, result of the unification of several TECO macro packages such as TMACS and TECMACS.
The "modern" Emacs, as an independant program (and not a bunch of TECO macros) built upon Lisp, came a few years later, taking inspiration from Multics Emacs and EINE (Eine Is Not Emacs) and ZWEI (Zwei Was Eine Initially) which opened the way for Emacs being written in Lisp (you should read the Multics Emacs article BTW, it's extremely interresting). GNU Emacs "a we know it" was first released with v13.0 in 1985.
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
"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
RMS hated Lucid. Really, really hated Lucid. He saw it as a commercial vampire sucking the life out of the MIT AI Lab. Google around and you'll find his essays on the subject.
When Lucid came to him with Emacs changes, it must have been kinda like if Microsoft started submitting multi-megabyte patch sets for the Linux kernel.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
>> Slashdot: The place where old computer jokes go to die.
Well only if you insist.
You know what the acronym emacs stands for?
That's right
Escape
Meta
Alt
Control
Shift
It has been statistically shown that helmets increase the risk of head injury.
Do daemons dream of electric sleep()?
From my perspective as an end-user, Unicode and bidirectionality support are the most glaring omissions of both Emacs and XEmacs. Mule development has moved slower than a mule's pace and, frankly, I'm tired of waiting. I think that, by the eve of 2006, there is little excuse for not getting these things done or putting them high on the priority list. Along with CJK and LGC (latin, greek, and cyrillic, Arabic script is one of the three most important script systems in use and in importance.
To be fair, there is only one product at all of which I am aware that gets these three issues right, SCUnipad
http://www.unipad.org/
In particular, its Arabic-script handling (including diacritics) is second to none. But it's not open source, development seems to have stalled (sigh), and it has few basic and no advanced features for coders aside from excellent unicode utilities. If any (X)Emacs developers are reading, I hope they will take a look at Unipad and consider implementing some of its features. I will be happy to consult on Arabic-script issues.