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.
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 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 %]
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