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.
WE need a poll!
Really, we do!
slashpoll:
1. VI
2. EMACS
3. Cmdr. Taco's notepad
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.
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 %]
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.
Perhaps it's just me, but I love new things. I think that's an important quality for one to have with ever changing new technology. If I have ever heard of a free editor, I have tried it. I love the possibility of infinite posibilities
Call me crazy, but I also like the idea of several people writing programs vying for my use of their program.
I don't know you at all, but I'm guessing we're fundamentally different in this aspect (so no reason to start flaming each other). Especially if you're using Windows and arguing in support of their unchanging editors. I hope you've tried textpad, I personally enjoy that much more than notepad when using Windows.
My work here is dung.
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
Emacs has all of those things, and pretty much anything else you can drum up from your favorite IDE.
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
Basically, the release criterion for Emacs 22, as set by RMS, is to fix all the bugs that the Emacs developers know of. No other software project nowadays (gcc, firefox, etc.) has this kind of criterion. It's been pointed out to RMS, several times, that Emacs 22, when it is shipped, *will* contain bugs; and that the only bugs that ought to be worked on close to a release are critical regressions. He has rejected this idea, which is why the Emacs 22 codebase is pretty much stuck in a pre-release state, possibly forever.
The trouble is that RMS's ideas about software engineering are rooted in the old days when the number of Internet-connected Emacs users was small and user feedback was rare. Nowadays, basing a release on fixing *all the bugs you know about* is a recipe for stagnation.
Are those actual professional programmers, or are they hobbyists who are too lazy to learn Eclipse? That thing saves so much time and frustration that I can't imagine not using it. If he wants to make sure it runs well on old hardware, it's not that hard to keep an old box around. I'd rather make sure it runs on new hardware, though. By the time that software gets released, most of the 500MHz boxes will be in the dumpster.
Besides, I've used Eclipse on my (completely obsolete) 600MHz box. It's not the fastest program to run on that machine, but it's perfectly usable.
Eclipse is great when I want to be productive. When I'm using eclipse, I have to close my mail client and my web browser and all the myriad of other distracting applications. The bloat(understatement) is a feature not a bug.
It has been statistically shown that helmets increase the risk of head injury.
Analogies don't equal equalities, they are merely somewhat analogous.
I've tried using Eclipse. First, it's slow. When you have to start an alternative OS (i.e. Java) in order to run your app, that's to be expected. It's also very big, for much the same reason. These things lead it to feel very clunky.
But, once I get past all that, it feels more like Eclipse gets in my way than helps me. It suffers the "Here, let me manage everything for you! You're going to do it all this way I expect, right?" problem that all IDEs suffer.
Lastly, I don't (and won't, it's a dreadfully stupid language) develop in Java. I develop in Python and/or C++. Eclipse doesn't support those nearly as well. It would be particularly nice if it could be scripted in Python, but I don't see that happening anytime soon.
Need a Python, C++, Unix, Linux develop
Not to turn this into another vi-vs-emacs flamefest, but what the hell...
:shell command? If the former, I'd like to know how to do it - it would be handy to use that when I'm on a system that lacks Emacs. The problem with :shell on vi is that you have to terminate the shell to get back to vi, and that you can't copy buffer contents to paste back to the editor. This is why I prefer to run my sub-shell in a first class edit buffer as with Emacs. (Of course, I can have multiple shells, and I usually have two or three. Don't know how to do that on vi either.)
I can compile, debug, run a shell - you name it, I can do it without having to reach for the mouse.
Ditto for vi.
Can vi(m) run a shell in an editable buffer, or are you just talking about the
Here's another killer feature that I'll bet vi(m) doesn't have (you have to use XEmacs for this, I don't know if plain Emacs does it): you can remotely connect to a running copy of XEmacs. Let's say I go home for the day, leaving a session of XEmacs up and running with various shells, debug sessions, and edit buffers. When I get home, I can SSH into my work box, run gnuclient, and connect a new UI to the running copy of XEmacs - all the same buffers, shells, debug sessions, etc. In MVC terminology, it's a new View/Controller connected to the same Model. Very, very handy. You can even do it with the local copy running in X mode, and the remote one in TTY mode (if your connection is too slow to support X). This is great for those projects where you want to work from home in the evenings after taking a short supper break. And, of course, when you get back to work in the morning, the original session is in sync with the remote session.
I've used vi for twenty years, too. I'm sorry to say that it took me five years to get around to learning Emacs. I'll grant you that vi has made great improvements since the olden days, but it still lags way behind Emacs.
As for gvim, if it's as butt-ugly as Emacs, then it's nowhere near Eclipse. Aesthetics is an area where both vi and Emacs are sorely lacking.
Eclipse plugins are a pain to write. Eclipse is way to abstract and high level, one needs to write about 10 classes to make a certain word a different colour in an editor. It does not make the life of a plugin writer easier.
Some operations really can take long enough (complex regexps in large datasets, or connecting to a dead nntp server, for example) that you'd really like to be getting on with something else while you wait, and you can't.
Still, there's lots of things I'd like to be kept.
While parts of the emacs fork had him looking like a petulant child RMS showed true integrity by letting it fork under the GPL and not changing the GPL as a result of the fork. When other people put stuff into emacs that would not help the hurd like X windows support RMS did complain and flame but did not try to take his bat and ball and take it home - because his text macros were turned into a GPL program that anyone could do anything with so long as they stuck to the licence. The actions spoke louder than the words.