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."
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
"We are already out about more bugs faster than we are fixing them, and the cause is simple: we are not working enough on fixing them."
Or, it could possibly be that they are discovering bugs faster than they can fix them. But it is hard to tell, it could be that they just aren't fixing them. But I am not sure. What was the problem again?
He who knows best knows how little he knows. - Thomas Jefferson
You can keep your windows editors ... wait, how many of them are there? Notepad and wordpad? At least I've got a nice selection with just a basic Linux install.
Not trolling but this works both ways. Install Windows, need to use an editor, so use one. Rather than evaluate which one of X editors I'd prefer to use.
Just to demonstrate why a lack of choice might be a good thing, which is better: vi or emacs?
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.
In the next 3 - 5+ years I think editors like Emacs will die a natual death. If you want to edit a simple text file in a *nix environment, emacs is overkill. But if you are working on a complex project, the IDE that are available today offer a lot more than Emacs.
I used to be a heavy gvim user, but I find myself using it less and less. On my Mac I use Xcode and Eclipse IDE.
Emacs has a fairly sharp learning curve. But once you have got there
it's still one of the quickest editors out there. The user interface
is very fast to interact with.
It's also very functional, doing most of what you want and quite a few
things that you have never imagined. It's also not an IDE--it's a general
purpose editing environment.
Finally, it's very configurable, and all of the files that configure
it are transparent. This means that my emacs setup works on different
operating systems and I can sync the set up between different machines with
the same program that I use for all my synchronisation needs.
I used to spend 90% of my day in emacs. More recently, I've been microsofted;
I have to use outlook for email (which is really, really horrible), and write
more word docs than latex. I really miss being emacs. My wrists are starting
to give in already.
Phil
I have know gone back to vim mostly ;)
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?
To a large extent, I use emacs because it is the only editor I have worked with that offers the comprehensive support for LaTeX that I need. The AucTeX environment has an absolutely amazing grasp of how the LaTeX process works and what support structures are required to speed development with extensive keyboard support. Of course, once you start using Emacs you start realising that it is really nice to be able to transpose characters, change case, transpose lines, have a working kill ring and amazing code editing support.
I have not found an editor that does as much to help me get my code on the screen in such an unobtrusive way. Because each major mode is not just a set of highlighting and indenting rules, but indeed a little customised editor, you get thousands of hours worth of tweaking for indenting code, adding helpful hints, language-specific doodads (the FORTRAN mode has special support for moving blocks and locating variables), etc, all with very little cost in terms of screen real estate. And did I mention good keyboard support? And the fact that the editor and keybindings stay the same in Windows, Linux and Mac OS X -- I'l take that above 'interface guidelines' any day[1].
I think the high integration of a good programming language (emacs lisp is quite good at doing what it does) also makes all of these things easier and more natural to develop, as a set of handy scripts easily transitions into a major mode.
I am constantly plagued by the idea that someone, somewhere is doing something more efficiently than I am, so I experiment with editors constantly. I have tried more than I can remember. If you have a good recommendation, reply on this thread, but for me the question has always come back to 'why _not_ emacs?'.
[1] I also think that interface guidelines are heavily weighted toward the inexperienced user -- emacs has a high learning curve, but like many professional tools, it pays back once you have learned to use it. Many people (like me) find it clunky to have to wade through seven levels of menus to find a feature when I could have just used M-x obscure-feature-name.
Languages aren't inherently fast -- implementations are efficient
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.
Or at least it did for me. Emacs has probably given me at least a year of time off (taken in small pieces and with some extra pain added in.) Apart from that (and the load time), it is a brilliant editor.
Eivind (now a vim-user.)
Doubting the existence of evolution is like doubting the existence of China: It just shows that you're uninformed.
Frighteningly enough, that might actually be possible. If you were to port Emacs to Movitz Emacs could become an operating system in actuality rather than as a joke!
http://common-lisp.net/project/movitz/
"I object to doing things that computers can do." -- Olin Shivers, lispers.org
I've used Emacs for fifteen years, and XEmacs almost as long. I have code (ps-print) in the baseline versions of both. I love Emacs because it made me productive like no other editor did. There are two factors in this equation:
First, I can use Emacs without taking my hands from the keyboard, ever. I can compile, debug, run a shell - you name it, I can do it without having to reach for the mouse.
Second, it is customizable in the extreme. Everything from key bindings to highlighting is driven by Elisp and regular expressions. Don't like the way something works? You can quickly and easily change it by rebinding a lisp function; most importantly, you can make these mods on the fly, without having to run a separate compile step, without having to restart the editor.
That said, I'm impressed with Eclipse. It has some amazingly good features in it; I particularly like the way I can highlight any variable, and instantly see its declaration, inheritance chain, implementing class, etc. We have some of those things, sorta-kinda, in Emacs with tags, but they're not as smooth and slick as Eclipse.
Eclipse has some weak points too. It suffers from Visual Studio envy. Its syntax highlighting is inflexible. Everything about Eclipse is too mouse-oriented - I have to reach for the mouse WAAAY too often for my liking. Emacs-ish bindings are available, but I find them more trouble than they're worth. (I forget why at the moment; I tried the Emacs bindings some months ago, and ended up switching back.)
What I'd like to see is an editor that combines the best of Emacs and Eclipse. You'd never have to take your hands from the keyboard. You'd get the attractive UI of Eclipse without the Visual envy. You'd get an editor that makes you more productive and happy than any other.
(Is something like this dream in Emacs's future? I haven't read TFA, but I rather doubt it.)
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 (
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
> 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.
Presumably if these are _new_ features, it would have to be OS X and Cygwin running under Emacs, since Emacs has been running under OS X and Cygwin for years. (The first time I ran Emacs under Cygwin, I was using Windows 95 OSR2 as my OS, and that was back in the days of yore, long before XFree86 was ported to Cygwin. OS X, of course, has _shipped with_ Emacs out of the box at _least_ since 10.1, probably 10.0 if I don't miss my guess.)
If this is indeed the correct interpretation, it is exciting news, since it implies great progress in the C-to-elisp compiler. I look forward to a day when I can get Gecko to compile for Emacs, so that I can get rid of that w3m thing and have a more mainstream browser on my Emacs system...
Cut that out, or I will ship you to Norilsk in a box.
> 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!!
Don't put exclamation marks on numbers like that; you'll confuse the math geeks, and 22 is a large enough version number as it stands, without taking the factorial of the factorial.
However, Emacs 22 is actually an abbreviation. It's really 0.22, of course, because Emacs also has yet to reach a 1.0 release. To reach a 1.0 release, Emacs would have to be essentially feature-complete, meeting all the major expectations people have of a text editor. I personally have a list of several hundred major features every text editor should have, which Emacs is still lacking. Perhaps the most significant has to do with threading and lazy evaluation: I'd really like to be able to do something like this...
(setq some-variable (lazy-eval (some-function stuff blah blah blah)))
(message "This stuff happens while some-function is still processing.")
(do-stuff foo bar baz)
(message "But now we're going to use some-variable, meaning that we'll have to wait for some-function to return.")
(message (concat "The lazy evaluation has now returned, and the result is " some-variable "."))
(setq my-child-process (fork (do-more-stuff)))
(message "The fork function should fork off an entire process and return the PID.")
This stuff would come in really hand for things like Gnus, for instance, and it's obvious to me that no text editor is ready for a 1.0 release without these features.
Cut that out, or I will ship you to Norilsk in a box.
Ultimately, I'm not sure that invented is the correct term. Created, wrote, initiated, started -- maybe. But not invented.
And certainly, RMS did not write all the GNU software, though he's certainly written a lot of it.
As I understand it, the argument that you're referring to is that `if RMS wants bugs fixed faster, he should fix them himself', right? If so, I don't see how it invalidates anything. Sure, RMS started the FSF and wrote much of the GNU software (including emacs) and he probably is still be the leader (I haven't watched the FSF politics in a while), but I'm not sure how that can invalidate anything.RMS should be familiar with the GPL and it's `no warranty' clauses. Even RMS isn't entitled to any sort of warranty with his GPL covered software, and he should know full well that if he wants something done with it, the only sure-fire way to do it is to do it himself. The grandparent post seems right-on to me.
Though really, if you read his actual post, it doesn't sound so unreasonable. And really, he only seems to be talking about a two week period, and it is December -- lots of people take vacations around this time, and may not actually be cranking away at emacs. He's simply asking for help, which lots of maintainers of projects do from time to time.
In any event, the /. summary talks about lots of new things in emacs -- cygwin support, MacOS X support, mouse wheel support. Obviously the work involved in all of these was completed long ago, because I already have emacs 21 on my cygwin installs, I recall having emacs on my MacOS X box, and if I fire up emacs on my Linux box right now, the mouse wheel works just fine.
Ahh, here's why the mouse wheel works --
Still, many of these issues seem like they've been there already for a very long time.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.
That's an advantage?!? Most believe that it's a liability. Sure, as you point out, nowadays Lisp programmers (particularly elisp programmers) are fewer and further between, and hence libraries harder to find. But Lisp is almost universally acknowledged to be a superior language to Java, and offers features essential to writing a programmable text editor. And elisp really isn't that hard; it is different, but the learning curve is fairly shallow: one can easily go from customising variables to writing functions to customising keybindings to writing whole modes.
True, emacs is an acquired taste, but like most such it's worth the effort to acquire.