I don't even know what features of Emacs I use. I have mental intents, actions, transformations, things I want to do to text, files, buffers, regions .. my conscious mind has been locked out of the tight-loop, the vicious cycle of a synapses being fired and keys chorded. It's all muscle memory. The perfect coupling of an average biological agent, and a bubbly, baroque piece of antique Lisp technology. Together, battling RSI and worse keyboard layouts, we sculpt scratch buffers to all sorts of works, many of adequate quality, but some exquisite.
Yeah, i once gave a emacs introduction in school and people asking me how i do X, Y. I needed to watch my fingers to tell them.. that was a bit confusing ;)
I have this problem with (random alphanumeric) passwords. When I needed to input my password on my phone, I actually had to draw a keyboard on a piece of paper and mime typing it, watching which keys my fingers hit and writing down the character.
But I don't get this with Vim. I think it's because Vim is a kind of composable language, so although you don't actually know at the time what you're doing, if someone were to ask you how you deleted half the line so quickly, you can work it out: "f)dt:". I think this is the reason I have trouble learning Emacs: it's not so obvious how commands are composed. There are some chains like C-h which are, but for the most part it feelings like there are just too many pieces. I've given it a good shot, and I'll probably try again, but it just doesn't feel as easy as "'d' to delete".
I remember one password that I had committed to muscle memory. I burned my hand one day cooking, and had to have my hand bandaged up for a week (note to self: don't try grabbing the steel handle of a pan at 450°F without a mitt). I couldn't type my password from muscle memory with my hand bandaged. I even knew the phrase that it was based on, but after many tries, I couldn't reproduce the exact set of upper and lowercase letters and letter substitutions that I had used. I eventually had to give up and change out all of my passwords and SSH keys, because I just couldn't recover my own password without my muscle memory.
I absolutely agree with you on the passwords. When I once accidentally typed my password into the username field, I thought: "...this is what my password looks like? This can't be right."
I enjoyed the article, even though I am a VIM fan. Many of the same advantages apply to VIM too.
At the same time I thought it was also like looking into a different culture. "Easy" meaning "copy and paste what a user tells you?" I guess there is a different view of easy.
The disadvantages struck me as rather interesting. I am not entirely sure why you need multithreading in a text editor for example. Perhaps someone could enlighten me as to when this sort of thing would help. Is it about running a compile job in one buffer while editing in another?
I also noticed a big reason to use VIM or EMACS over an IDE that seemed missing and that is that both these editors have tons of features for gracefully editing large numbers of large files. The IDE's I have worked with haven't come close here.
For now I will stick with VIM, which I feel comfortable and confident on. However, seeing folks talk about the benefits of the other is interesting.
I am not entirely sure why you need multithreading in a text editor for example. Perhaps someone could enlighten me as to when this sort of thing would help.
Basically, the lack of multithreading prevents any sort of background processing (unless it can be implemented using an idle hook, which often isn't possible.)
For example, Gnus (a newsreader which can also be used to read mail from a POP or IMAP server) locks up Emacs while it is checking for or fetching new mail. This is quite painful when fetching mail over a slow line or from a slow server, and causes people to do hacks like mirroring their mail onto a local IMAP server from where Gnus can fetch it more quickly. But even then, there is a noticeable pause when the server is accessed.
Gnus is an awesome piece of software and having all of Emacs editing capabilities at hand when writing mail is fantastic. I'd use it as my primary mail client if it weren't for the multithreading issue.
Not sure why you'd mock this use of Emacs, after all mails are text and as such very well suited to being composed with a text editor...
My MUA (Mutt) can launch any editor you like for composing mail. I use Vim, but it would work equally well with Emacs, nano, or whatever you prefer. Mutt is not alone in this regard.
The point is, you don't have to have embed your MUA inside of your text editor in order to use your editor for composing mail. There's nothing particularly wrong with that approach, but it's not the only way to get that benefit.
I agree you don't have to, but if the interaction gets more pervasive, such that the points of interface become many, it can be easier to just implement it in the same environment. If you just want to edit mail in vim, that's one thing, but if you want to be able to use commands in the mail editor to contextually interact with the rest of a mailbox (highlight a URL and search your mailbox for other occurrences of that URL, or add an email address to your address book, to take simple examples), it becomes more like the IDE case. Either you have to implement the IDE in the editor's scripting language (the emacs approach), or you need to call out to a number of special-case Unix tools to implement each of the hooks (the vim approach).
I write all my work e-mail in GNU Emacs and use the Emacs VM mailer.
Because it's all inside Emacs, text from other contexts -- code, shells, mailboxes, and compiler and tool output -- can be accurately and quickly pulled into the messages you compose, improving the content and reliability of what you're saying in mail.
For example, if I want to use a complex identifier from a source file I've just looked at, I can autocomplete it (M-. or find-tag) quickly from a substring. I can choose autocompletion suggestions simultaneously from all contexts.
Obviously, copying and pasting regions from those other contexts is much more immediate too.
This is in addition to the advantages of having a familiar and powerful editing tool for formatting, tidying up messages, trimming unnecessary content, etc.
> Not sure why you'd mock this use of Emacs, after all mails are text and as such very well suited to being composed with a text editor...
Vim user here. I use mutt for email (which opens vim for editing emails), Vimium for Chromium, and I've set vim to be my default editor, my shell accepts vim commands, and my tiling window manager uses vim-style keybindings.
So, I almost never have to do anything in an environment where I don't have access to all of the power of Vim... and yet my text editor remains simply that - a text editor.
No problems with multitasking, because I've never needed to do more than one thing at a time in Vim, and I can't imagine ever needing to. All of those things that you're thinking of as separate processes in Emacs are things that I delegate to dedicated programs that specialize in doing those things. But I can get all of that modularity without sacrificing any of the vim key integration.
Not trying to sell you on using Vim, but just trying to explain the different reasoning.
I wouldn't mock it, actually, but others ("fanboys") do.
I got that, sorry if my reply wasn't clear. When I said "not sure why you would mock it", what I actually meant was "why one would mock it".
Anyway, as I've argued before [1] the whole Vim-vs-Emacs (and Emacs-vs-Vim) fanboyism is sad and a waste of many talented people's time. Can't we just get along and instead focus our efforts on converting the legions of people who understand neither Vim or Emacs and embark on writing the n-thousandth Notepad clone? :-)
Well, considering that Emacs is supposed to integrate smoothly with external processes, it looks that asynchronous IO support it will be a better solution. Multithreading is generally a tricky business for interpreters and virtual machines.
So to reduce editor interface freezing, looks like a dead-end: either you expose asynchronous IO (like AJAX), or you add the complexity to have a multithreaded interpreter (like JVM) or implement a sane concurrency model (like the actor model in the BEAM machine). Or else avoid Emacs modes that are known to freeze.
However, I recently discovered that VIM uses threads:
$ ps -eLf | grep vim
UID PID PPID LWP C NLWP STIME TTY TIME CMD
etanol 15073 15023 15073 0 2 22:23 pts/2 00:00:00 vim
etanol 15073 15023 15074 0 2 22:23 pts/2 00:00:00 vim
Unfortunately integration with other processes does not always lead to the expected results and many tools have been reimplemented in Emacs Lisp to integrate better with the rest of the Emacs platform. Suddenly, not having multi-threading becomes a real issue (Why the heck is Gnus taking so long and why can't I edit in the meanwhile?).
Some might say that it is insane to use Emacs for every conceivable task, but it offers me exactly the degree of integration I'm after, a uniform UI and a disruption free environment for most of my computing needs.
Multi-threading is asked for because when you run a complex thing in a single buffer (i.e editing something over Tramp mode, compilation, magit doing Git operations etc.) it can block the editor.
Hence, multi-threading is a potential solution to that.
Contrary to how Vim is usually used Emacs users tend to start only one Emacs instance and spawn multiple windows from that. This is because using a single Emacs session has certain advantages (completion, searching buffers, start up time (mostly a thing of the past now), etc.).
However one disadvantage is Emacs not responding when it is busy with something else, like f.e. someone else mentioned Gnus retrieving mail. It doesn't happen often but it is annoying. I tended to use a separate Emacs instance for Gnus in the past.
> Contrary to how Vim is usually used Emacs users tend to start only one Emacs instance and spawn multiple windows from that.
I have seen new vim users opening multiple vim sessions, and copy from one to another with the mouse, and mess the indenting, etc. Experienced user would open one instance instead.
Multithreading would be a great feature, working with an editor where the whole UI tends to block itself on some network (tramp or via sshfs/nfs) operations is unpleasant. It's also a sign of its age. I also miss, for example, UI localization. You can, of course, have everything hardcoded in English, but it's a limitation. Well, whole UI is dated. In (g)vim you can have nice pop-up code-completion, in emacs, it's not that nice. The UI is very dated, sadly.
I am not entirely sure why you need multithreading in a
text editor for example.
I can see a few uses for it. The big one for me is semantic analysis. Intellisense is a surprisingly large computational burden, for a single example, and moving it and things like it off the thread that's handling your UI is probably a good idea.
>I am not entirely sure why you need multithreading in a text editor for example.
People often interact with APIs in Emacs or with things like git repos. Being able to make non-blocking calls to HTTP APIs and such would be rather nice.
I am a bit annoyed by all these emacs / vim / sublimetext vs. IDEs articles. In an IDE, the editor is a small part of the overall program, and it indeed does often suck compared to the godfathers. But it's such a small part of the actual task of working on software that I'm ok with a few tradeoffs. On the other hand, whoever ever tried to debug java or c++ in emacs, or even worse, debug a single app consisting of php, ruby and javascript in emacs is going to enter a world of pain. A task which is pretty easy to accomplish in Intellij IDEA.
Eclipse makes it pretty easy to keep the muscle memory with its emacs+ mode, which is quite good (it even has ido and M-x). You lose the elisp, but have a real IDE nonetheless.
It's all about the work you need to accomplish, I find myself much more productive with a less capable editor, but a full IDE. And I still use emacs a lot for org-mode, editing config files, writing smaller programs. But emulating full IDE features is just to painful (most of the time).
The only area where Emacs is actually a brilliant IDE is when using SLIME (for Common Lisp and Clojure).
> But (the editor is) such a small part of the actual task of working on software that I'm ok with a few tradeoffs
You have to understand Eclipse and the tools most people use it with evolved together for a long time. That creates this dependency between IDE and toolset - it's more or less impossible to be productive in Java without an IDE. There are, however, languages and technologies that didn't evolve together with IDEs and employ fairly easily hand-editable files instead of overly complicated things no human hand is supposed to touch.
Emacs' brilliance is in how it's built in itself and how one can shape it to its needs. For instance, it took me a couple minutes to configure mine to start with different fontsizes and screen layout in accordance to the size of the monitor I'm using. I cannot imagine the level of insanity I would have to go through to do it on Eclipse.
What languages are these though? I switched over to eclipse for C/C++, and these are fairly well integrated in emacs to boot. I just find it more comfortable to write in that in eclipse, and most of the navigation and editing commands I have in emacs work perfectly fine in eclipse with emacs+.
I moved over to intellij for java (of course), php + javascript + html (the ability to debug php and javascript side by side is very nice), and python (although that's one that works pretty well in emacs as well).
I guess I'm biased though because i find the navigation layout and the autocompletion visually much nicer in editors like eclipse, whereas due to my laziness I never configured emacs to be "visual", I still use it inside tmux in a terminal, without graphical widgets.
That said, I'm a happy multiuser, I'm just a bit tired of the emacs over everything, while IDEs have their own intrinsic advantages. Maybe I'm just a discokid, but I like having to click 2 buttons to update my pom.xml rather than going in by hand to edit the xml, or having to figure out if the maven.el file I found somewhere is still usable.
> it's more or less impossible to be productive in Java without an IDE
At my last full-time Java job most of us used Emacs and we got along just fine. I think the real trick is not to write shit code.
Another job I had I used a dialect of Lisp (won't name any names...) which relied pretty heavily on an IDE. It was painful to work in the IDE or in Emacs, but that's because it was shit code.
Behind emacs and vim are two long stories of old programs constantly adapting to new environments, yet growing to have capabilities that IDEs never got.
I find it interesting that this class of articles has such an appeal to Hacker News readers.
If this were an article about hammers, and how good they are for driving nails, people wouldn't care. If this were an article about saws, and how they are for cutting wood, people wouldn't care.
To me, the article is exactly like the examples above. Take some widely used tool and say what it does. It's common knowledge and I don't care that you use a particular tool exactly the way it's advertised.
Now if this were an article about using hammers for something they were not designed for, of about using saws in creative ways, that might be interesting. It might also be interesting to talk about what you build and how common tools made a difference for your product.
Woodworking magazines are full of articles about tools and how they're used. The most interesting pieces are invariably about how the tool changes the user - how Japanese saws change your mental approach to jobholding, or how routers tend to displace other tools and skills.
At a sufficiently high level, any discussion of craft inevitably becomes a matter of philosophy. The tools in a shop tell you about how a woodworker relates to wood; His attitudes shape his tool choices and his tools shape his attitudes.
This analogy is exact. At the beginning levels people argue about power tools versus hand tools; shooting board vs. chopsaw, japanese plane vs. iron. Professionals have their tools that work, are interested in new tools insofar as they can improve results or productivity, but don't engage in recreational arguments.
Masters of the craft have no dogma about tools and are always exploring, but also have strong opinions. They will rarely broach the topic but if someone is interested will talk for hours about their favourite tools. Their emphasis is on how the various tools change the process of work, not on how they change the work itself - the piece will be what they want it to be regardless of the tool. It's the worker-tool interface that's important at this level.
Yep. I spent a weekend with a group of sculptors once, and they were debating the merits of particular drills just as eagerly as we discuss editors. Tools matter when you use them the whole day, every day.
Though still it should be noted that most of programming is thinking, not typing ;-)
Actually given the image you want to sculpt the rest of the work is 'knocking away the parts that don't belong'. This often takes most of the time in the overall process. There is also the matter of mounting the piece. This can take from zero (for free standing pieces) time to significant amount of time depending on the problem(s) involved. Overall I'd have to say that after 30+ years, doing the work takes more time than thinking up the idea. It's hard to be exact since it depends on hard to quantify things like how you come up with your ideas---many of mine were dreamed up while doing things like kiln watch (someone has to be around when you are burning the wax out of molds for casting bronze). Or when you are just sitting around with other sculptors and bullshitting. Something gets said that leads to an idea etc. Given the way the mind works, it would be hard to say that the thinking process starts 'NOW' and ends 'HERE' leading to time to pick up carving tool etc. Since I long ago came from the art department side of campus, I highly recommend taking some of these courses not just to get those non-major credits, but to give yourself other boxes to think in when you have to think outside the box. Must stop now, beginning to babble :)
The simple tool analogy is flawed, I think. A hammer, saw, or screwdriver tend to do one, maybe two (in the case of a case) things well. A programmer's editor will often need to do lots of thing well (or, at least a few, specialized things well).
That said...
To me, the article is exactly like the examples above. Take some widely used tool and say what it does. It's common knowledge and I don't care that you use a particular tool exactly the way it's advertised.
I agree. Of course, the opposite side of the coin is that sometimes, people who don't use the tool in question need to find a nice, concise overview of why this tool is really swell, rather than "anti-patterns in tool x." So, I can live with a few "my_editor_of_choice is awesome because" articles. It's easy enough to not click on a link.
I think more complicated machinery fits the analogy better. Photography, for example. For many people a simple point & shoot camera is good enough (e.g., notepad). They start quickly, they are cheap, and they get the job done, but push the boundaries and you'll wish you had more. For others who want more power, there are digital slr cameras with a wealth of features available (e.g., VS/Eclipse). Then there are those who insist that their 1970s vintage film camera will always outperform the latest technology (e.g., Emacs/Vim).
Another analogy that I thought of was heavy machinery (they are complicated machines that are designed for complicated tasks), but I have no idea if there are construction workers that discuss the merits of Japanese vs American earth mover design or think the controls from some 1980s era Russian dump truck can never be matched.
To me, the article is exactly like the examples above.
No, it's not.
I have been a casual user of emacs, in the past. It did not seem like such a big deal to me: as a text editor it seemed better than average, but the arcane commands needed to get anything done seemed non-sensical.
Then, reading an article like the one linked, I learned about org-mode. Which was the hook that got me into using emacs for 90% of my texting needs.
Hammers do one thing, really well, but it's as if, after a lifetime of using a hammer to drive nails I talked to my neighbor and found out they have dozens of other uses.
I love my estwing hammer. I don't want anyone to take it from my toolbox. But I don't care what hammer you use; so long as you know how to use it and are happy with it.
At school, I’m known as the Rock guy; when people have questions about using a Rock and hitting things a certain way, they often come and ask me. Sometimes, some people ask me why use a Rock to hit a nail? Isn't it a really an ancient way of doing things and wouldn't a hammer be much better?
I guess this has to be a parody, and yet if this article actually existed I would click on it immediately.
Learning how other people use tools is what technology is all about. Otherwise you will make dangerous assumptions, like "of course my cutting tool is sharp; the reason it's cutting so slowly is that hand-powered cutting tools are always slow." Or "obviously space aliens made this artifact, because what society could have built such a nifty thing using nothing but rocks?"
People like to talk about the tools and techniques they use regularly.
Hackers and "people" might not be interested in hammers, but I can attest that if you get a group of blacksmiths together in a pub, they will spend entire evenings talking about different kinds of hammers, techniques for striking, etc.
Excellent article! I agree with all points here. I think one of the most important is "Emacs is easy to configure". You just Google a problem and copy 2 lines in your .emacs. No need to click here and there, then find out you have to do it every time you open the editor etc.
Also one thing that has gone true in the last 15 years (but most devs seem to still ignore it), is that emacs now has a small footprint and starts fast compared to many IDEs.
>> Also one thing that has gone true in the last 15 years (but most devs seem to still ignore it), is that emacs now has a small footprint and starts fast compared to many IDEs.
I have started using emacs recently, coming from Eclipse, and this is the main point that has led me to it. I use a netbook at home with only 2gb of ram, and it absolutely takes forever to open up eclipse (even the most basic 'classic' eclipse install), to the point where I was dreading opening it up to start coding.
Another significant factor is that, when I started learning Scala and then Clojure, I noticed how dependent on the tooling I had become from using Eclipse in Java projects. For languages that do not have a mature set of tools favoring eclipse, than you're left with a really heavy and slow text editor. I noticed it was a terrible trade-off.
When I asked myself 'what programming environment is lightweight but goes beyong syntx highlight?', then it came down to emacs and vi, that I heard of. Since my particular interest was in lerning Clojure, emacs fit like a glove.
I'm still not really that productive, but in the long run I find that I'll gain a lot more from learning to hack in emacs.
You might also want to look into running emacs as a daemon, if you haven't already. Since it runs as a server in the background (with a grand total of maybe 30MB used in my case), clients pop up instantly and if there were buffers open on the server from before, they will remain open even if you close the client's window. If you start/close emacs more often, it's definitely a nice thing to have.
emacs --daemon
clients are called using either
emacsclient (for either terminal client or gtk/x11 client)
emacsclient -c (to open a new frame)
emacsclient -t (to open a frame in the current terminal)
Wow, I did not know that emacs could be run in a terminal mode like vim. Thought it was GTK/GUI only. No excuse not to install Evil and give it a shot now.
Initially I started using emacs for AUCTeX, a great extension for LaTeX. Now it's become almost it's own OS as I can run Matlab (using Matlab mode), and several terminals from it (using ansi-term). If you're using ansi-term, just remember that C-c k is char mode (direct terminal entry), and C-c j is line mode, allowing you to use the power of emacs.
ansi-term in line mode is basically the same as shell, however you still have the option of direct terminal entry with char mode, which is sometimes useful, ie when looking at the command history of a machine you sshed to. ansi-term can also run more programs (ie some graphical programs, man).
I think the question for me would be why should I——or anyone for that matter——use Eclipse or Visual Studio instead. Emacs is not an editor, it's a keyboard language used to modify files and run programs. Further, those are editors where extensions and settings are each a separate feature instead of a natural flow of blended editing, reconfiguration, and extending. With Emacs, the question is never about if some editor feature is available or if it can be scripted together. With Emacs, the first and only question is always How? as Emacs will simply turn into anything if only so told.
Anyone for that matter? How about people who find Emacs to be archaic with weird key bindings and who don't care to spend half their time fiddling about with lisp scripts. Don't get me wrong, it's an awesome tool and I spend a long time using it - but it's not for everyone and bemusement at why that may be the case is being short sighted.
Aw, before I clicked through, I guessed this article was from the 90s - I was sure that vim had taken over the world by now. Goodness gracious, folks, it's 2012!! :-)
In all seriousness, although these are all good points and I'm quite jealous of Emacs' tetris mode, I think you're missing out on one of the best features of Emacs: shell mode. IMO shell mode (or whatever it's called) should easily be at the top of the list. I wish there were a decent analogue to this feature in vim but there really isn't, just a bunch of not-quite-there plugins...
It's against VIMs design philosophy to include a shell. The idea is that you shouldn't use shell (and other things) from vim, you should use vim from your shell. You have access to your shell by using the :! command.
There are at least three shell modes built in (there are probably more).
shell mode (M-x shell) - gives an interface to your system shell, can handle everything except programs like top, you can move around past commands which is a dream.
ansi-term - an actual terminal, better for top et al, can switch between terminal mode and emacs buffer mode
eshell - shell implemented in Elisp. have never used it, but i'm sure it's awesome.
Dired mode is also wonderful, navigate to a folder, simple one key commands to do most of the basic shell copy/rename/move commands, with simple searching and all the emacs shortcuts.
What makes eshell awesome is mostly that it blurs the lines between bash and elisp, you sort of kind of can use them together. Unfortunately the manual does not do this feature justice as it is largely incomplete. This article is the best i've found.
You can dired into a remote directory via ssh, start a (remote) shell there and have local command editing with working command & file completion. Works wonders for remote work over high latency links.
Why I still use emacs: I've been using it for 10+ years and my fingers and general workflow are very very used to it. I regularly use vim (for quick editing and vimdiff), but keep coming back.
If only emacs had a "project drawer"/"tree drawer" like textmate, then it would be golden. ecb doesn't quite cut it for some reason, I keep reverting to textmate each time I need to get an overview of a huge source tree I'm not familiar with.
Out of curiosity, if you've used emacs for 10 years I'm assuming you're familiar with ediff; what do you find so useful about vimdiff? (I've never used it, so I'm genuinely curious)
Generally I use vimdiff when working with tests and use it for diffing between the expected output and the real output. It's run in the terminal as opposed to inside my huge emacs process and I don't really know why else I don't use ediff, vimdiff is just part of my editing workflow.
Neither those nor emacs-nav come close to working and looking the same way the file tree drawer in TextMate (or other IDEs) does. speedbar only shows directories, not files, when I navigate dirs in it.
Thanks! In org-mode I can even access list nodes within the files in the SpeedBar immediately!
I agree with markokocic: Emacs is brilliant. I tested many editors but always returned to Emacs. In the beginning Emacs is a pain to learn but once you get it it's indispensable.
As a vim user, I had a bet with a coworker (emacs user): we would switch editors for a week, with the goal of learning another tool for our daily work. Every time one of us complained, we would pay the other $1.
I haven't switched back to vim -- that bet stopped back in November.
One of the best things that happened to Emacs in recent years, IMO, is the Evil project (see my blog post for an Emacs user's perspective on it: http://dnquark.com/blog/2012/02/emacs-evil-ecumenicalism/) -- now you don't have to choose between the power of Emacs an the terseness/efficiency of Vim and modal editing. After installing Evil, I've taken to calling Emacs "my thermonuclear editor".
I am an GNU Emacs user. The major problems I see are:
1> lack of Multi-threading
2> Support for multiple major modes
The 2nd problem is the biggest I suppose. Present day development deals with chunks of code in different languages, all put in the same file. It just kills me to code Python+JS+HTML in a single file, pathetic support.
I feel the pain too. MuMaMo doesn't quite cut it for HTML + ERB.
That said, I never run into this when working with Clojure, since both the major templating solutions (Hiccup and Enlive) use only one language per file (Clojure and HTML, respectively) and I can keep my JS cleanly separate, barring the occasional Google Analytics snippet.
> Present day development deals with chunks of code in different languages, all put in the same file. It just kills me to code Python+JS+HTML in a single file
That got me worried - you probably don't need to suffer this. What are you using this multilanguage file for? You shouldn't put lots of JS inside HTML and certainly not embed Python code inside it (nor the reverse).
I understand that we should try to maintain different files for different languages. But in huge projects it is inevitable that you come across situations where you embed js/css in html, php+html, etc.
The noweb mode for R and LaTeX works quite well (in my experience). I would imagine it would be possible to hack something together using that as a base.
I use emacs and have done for ~ 20 years, but I don't think this article would sell me on it if I didn't already.
An editor is just an editor: an editor with a variety of unrelated crap (text adventure, tetris game, mail reader) bolted on the side is not obviously better, it might just be bloatier. The compelling feature of emacs is its extensibility and self-documenting nature: that Gnus exists is not a big deal, but that you could invent it if it didn't already exist - that's where the magic lies. Emacs is a habitable programming environment.
"First off, we didn’t need to restart emacs. In fact, we didn’t even need to load any files. All of this was done on the fly. Second, we didn’t at any point have to read an info manual, fiddle around in the filesystem, or search a web site to get to the documentation for anything. We had a little help from customize to tell us that ispell-message was a suitable function for this hook, but aside from that, all we needed to know was in function and variable docstrings."
Spot on. Adding functionality to Emacs is a matter of typing or pasting some elisp and executing it. There exist IDEs where you need to setup and build a project with an XML based config for this purpose :)
There's an interesting Clang autocomplete mode. It is almost great, but falls short a bit for obj-c. If you deal with C/C++ all day, you should definitely check it out:
I agree to a lot of the arguments, but for me most of them fits better to VIM. I really have nothing against Emacs, but I just happened to start learning VIM, and after that it's been hard to change.
In my university, there's really only some Java and Python we have to learn, at least the first couple of years. Since I like to learn a lot of other stuff, I kind of had to learn an editor. But most of my classmates has never programmed outside eclipse or whatever IDE they use for python. I really don't get how this is going to make us good computer scientist.
I once used that. I remember for extra power and/or hilarity I configured it so that emacs commands were all available in vi "insert mode", so that Esc effectively switched between vi and emacs.
The writer says he thinks Emacs will evolve and get some IDE-like features, but do you guys think Emacs will keep on evolving? Is development still active or dead like in Vim?
Vim 7 added a lot of new features. Bram typical does fix releases for a while and then there is fast and furious to the next version. Vim is definitely still being developed.
