Why I Still Use Emacs
gnuvince.wordpress.com
gnuvince.wordpress.com
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 ;)
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".
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.
Hence, multi-threading is a potential solution to that.
Edit: spelling
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 not entirely sure why you need multithreading in a
text editor for example.
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.
If I want to read an email I simply switch to my email client, thus virtually eliminating (almost) all risks of Vim/Emacs crashing.
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...
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.
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.
I could, but wouldn't want to, live without it.
You are right, emails are texts. Managing emails and contacts and calendars can go (and usually goes) well beyond text editing, though.
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? :-)
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.
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
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.
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.
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.
IDE stuff mostly.
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).
And frankly, eclipse's editor is crap.
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.
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.
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.
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.
But which people? I'm sure those who use hammers every day care about how they are used and which ones are the best.
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?
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?"
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.
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.
http://www.lowtechmagazine.com/2010/12/hand-powered-drilling...
http://steve-parker.org/articles/others/stephenson/holehawg....
If most people bought and used expensive, complicated hydraulic machinery to drive nails -- then I think people would care about such an article.
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.
Though still it should be noted that most of programming is thinking, not typing ;-)
Why do you think programming would be different?
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.
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.
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.
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.
emacs --daemon
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)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...
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.
http://www.masteringemacs.org/articles/2010/12/13/complete-g...
And of course eshell is just a buffer so you can surf through the output with all the available commands you typically use.
If that relies on TRAMP then I am not impressed. (TRAMP is slow and seems to stop working after a while.)
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.
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.
I haven't switched back to vim -- that bet stopped back in November.
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.
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.
Either way, the code looks/reads a lot cleaner if you include the JavaScript as a separate file referenced from your HTML. Solves 2 problems.
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).
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.
If HN lets me post links in comments, here's an example from a little while ago showing how I once extended the Gnus email composer to check for missing attachments - http://ww.telent.net/2003/1/14/_updated_for_elisp_syntax_err...
"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."
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.
For C++ i would use QT Creator. For scripts such as shell , Python VIM is great.
You don't even have to ever turn it off!
Also, since it's a Lisp machine, it doesn't necessarily need to have IDE features added - you can just write your own extension in Emacs Lisp.