Emacs is terrible

It's simply impossible to become as quick in Emacs as one might be in vim. I've been trying, I've really been trying hard to like Emacs, because I want a decent IDE for Lisp. But it's just terrible. The editor is always getting in my way.

I have a new purpose in life. To clone vim in Common Lisp. This isn't reinventing the wheel, because whatever vi-mode they have in Emacs is still corrupted. A new viitor must surface, pure and handsome, with all the Lisp-friendliness of Emacs and all the awesomeness of vi.

I just wanted to get this off my chest, /prog/.

I've been too lazy to learn vim, and Emacs was my first love. But it's terrible and I must break away from my laziness and use vim.

>>41
Wut. Are you leaving Lisp for C++ too? That's about as rational.

>>39
You've adequately proved that Vimmers are the kind of people who optimize random portions of their code rather than saving their effort for inner loops. Now, why is this useful?

>>41
I had the opposite experience about a year ago, and am happier with emacs.  A key factor in this was that emacs has better help facilities built in which made it much easier to learn. Different strokes for different folks, I guess.

After five years, I switched from vi to Emacs.
After another five years, I switched from Emacs to acme.

Notepad
Editpadpro
notepad
vim
notepad
vim...

>>43
That's a pretty nonsensical conclusion.
That specific example was bad, yes, but this kind of stuff is always useful. For example: at work I often have to edit other people's html. Sometimes I have to mass change/add classes or modify lots of little things quickly. Vim's recording features, regexp support and editing modes (like visual block) make complicated tasks easy.

>>44
Different strokes indeed. I always found Vim's help much easier to deal with. :h <whatever>, that's it. Emacs' help command is confusing.

>>47
I have no intention of changing your mind, but emacs can record keyboard macros, it supports regexps and you can edit blocks too :)

>>47
html
classes
wat

>>49
You completely missed the point. Emacs can do anything, everybody knows that. But in Vim I do it disconcertingly quickly, with just a few keystrokes.

>>47
I don't believe the time spent composing a macro could ever vary significantly because of how easy the keys are to press, even if you assume that the user has not learned to operate their modifier keys.

>>51
You're completely missing the point. Shaving keystrokes off a task the speed of which is not bound by typing is pointless.

>>51
It doesn't take more than that in emacs. Take visual mode, for instance, you would use v to enter it and you would move the point to highlight what you want. It's the same thing in emacs, but you use C-space instead of v.

If you think about it emacs and vim are actually pretty similar, they just have different design goals and hence highlight different things.

>>52,53
You're completely missing the point. A Vim user internalizes the commands in a way that he barely has to think before achieving something. This is possible because of the way Vim's commands were designed - the operator/command/motion setup, and because of their short length. How familiar can you get to a long combination of C-crap? When composing a macro, what matters is how quickly you can get your thoughts to the editor. And in this aspect Emacs is unimpressive.

>>56
I can honestly say that in 99% of cases, I have to look at the keyboard to know which command I am pressing in emacs. THIS IS THE CASE FOR EVERY PROGRAM YOU USE A FUCKLOAD.

When composing a macro, what matters is how quickly you can get your thoughts to the editor.
This is what vimmers actually believe

Mastery of vi can be compared to the mastery of kung-fu. The young apprentice must harden his body and enhance his strength; only the toughest may survive. He must be accostumed to difficult situations, and the best way to practice is by complicating his everyday habits. He shall not use the pathway when he walks to the mountain - he must go through the jungle. Likewise, the vi user begins his journey by getting used to the idea that he will never touch arrow keys again: he must instead replace them with hjkl.

>>59
Does Vi Jesus reveal that the world is wireframe in the end?

>>59
Nice, but one thing bothers me
Likewise, the vi user begins his journey by getting used to the idea that he will never touch arrow keys again: he must instead replace them with hjkl.
There is nothing wrong with hjkl or C-f,C-b,C-n,C-p, and I don't know why so many people complain about this. If they want to use the arrow keys they can, quit whining like little children.

>>61
what about them being miles apart on the keyboard??

>>61
They are easy enough to remember: forward, backward, next, previous and were chosen because of that.

The only way that their distance would be a problem is if you are not a touch typist (in which case you should be using the arrow keys anyway) or you are playing games inside emacs, which, while possible, is where I draw the line.

>>37
One thing I like about Emacs is that the commands are modified in obvious ways. Take C-k, this kills a line (d$ ?). what if I want to kill a sentence? M-k. A sexp? C-M-k. Transposition is similar C-t = transpose letters, M-t is transpose words and C-M-t is transposing sexps. And emacs' modes allow for mode specific nuances without having to relearn a bunch of commands, e.g. C-j (newline-and-indent) does language specific indentation.
These are not great examples of commands you would use on a regular basis, and some are lisp-centric, which is an unfair comparison since emacs is obviously tailored to lisp (uselessly so, for 99% of developers), whereas vim is much more general purpose.

Your example of "obviousness" also makes no sense. Why does M+k kill a sentence but M+t transpose words? This is not symmetric at all. All you know about M versus C is that it's 'bigger'. How do I kill a word or transpose sentences? Killing words and transposing sentences would seem far more useful than any of the commands you mentioned; in particular, the killing n words combination in vi is probably the command I use the most doing any kind of text editing.

That being said:

kill a letter: x
kill a word: dw
kill a line: dd
kill a sentence: v(hx
kill a sexp: v%x
transpose letters: xp
transpose words: dwwP
transpose lines: ddp
transpose sentences: v(hx(p
transpose sexps: v%x%p
newline and indent (and insert mode): o<TAB>

One thing you might notice about these is that none of them are actual individual commands in Vi. They arise naturally by combining much simpler operations of navigation, selection and copy/paste. This isn't possible in Emacs because it's not modal, so every character in the above would require combining with a modifier key. They HAVE to make high-level operations to make it useful, and you have to memorize a huge amount of them, because doing the selection and copy and paste yourself with modifier keys is actually really inefficient.

This is why I find vim to be so much more versatile and useful in text editing of *any* kind, not just programming (though I mainly use it for programming in a variety of languages, and for HTML/CSS.)

>>64
Sexps in emacs do not refer to them in the lisp sense, e.g. you could use  sexp commands on C blocks delimited by {}
From the manual
The other commands deal with expressions or sexps. The word `sexp' is derived from s-expression, the ancient term for an expression in Lisp. But in Emacs, the notion of `sexp' is not limited to Lisp. It refers to an expression in whatever language your program is written in. Each programming language has its own major mode, which customizes the syntax tables so that expressions in that language count as sexps.

Sexps typically include symbols, numbers, and string constants, as well as anything contained in parentheses, brackets or braces.

Killing words would be M-d (kill-word), which would be the "super" version of delete
killing 6 words would then be M-6 M-d (or C-u 6 M-d)

newline-and-indent (C-j) is just a habit I've got into, you can use return and tab if you want.

Transpose lines is C-x C-t

Oh also, >>64-san here, and I just want to say that learning hjkl is *not* important. I've been using vim for many years and I still use the arrow keys more often than hjkl; it's just easier, and the arrow keys are just burned into my brain.

You can still always use the arrow keys in virtually all scenarios. I really don't know why all Vim tutorials emphasize hjkl so much; that is something you should learn WAY after the incredibly useful higher-level navigation commands (such as wbe%(){}), and after you learn basic copy-pasting and visual mode.

The main place I really do use hjkl is when I want to combine it with # to do something quick; e.g. to delete a block of code, v5jx . This is when you should learn these, because they're only really quicker when you combine them with numbers (or when arrow keys are actually broken, i.e. if you're stuck in a misconfigured terminal.)

>>65
newline-and-indent (C-j) is just a habit I've got into, you can use return and tab if you want.
Ah but note that the vi command o doesn't require you to be at the end of the line; it opens a new line and jumps the cursor there.

>>64
I'd also like to take issue with your "they have to use high level constructs". You could build them together from other commands if you want to, but, and I shouldn't have to tell a programmer this, it's a stupid thing to do. It's like saying that you shouldn't use high level control structures because you have conditional goto.

>>67
A fair point, I don't believe there is a built-in that does this, but I suppose I could always write one.

>>69
Scratch that, there is a command C-o, but that acts like O in vim rather than o.

>>68
I'd also like to take issue with your "they have to use high level constructs". You could build them together from other commands if you want to, but, and I shouldn't have to tell a programmer this, it's a stupid thing to do.
That's the whole point, it's a stupid thing to do *in emacs* because it's inefficient. Whereas it's extremely efficient in Vi.

In Emacs, I just press Enter for newline and indent.  If I'm at the end of a function/macro/definition/... it would just place the cursor at the start of the line, which is the behaviour one would normally want.

>>71
Even if I agree it is the `vi thing to do', why go through this every time? Why not bind your own key? Presumably you can.

It's a stupid thing to do *in emacs* because it's inefficient.
Nonsense, it's not any more inefficient than vi in the common case, since if you are doing multiple commands you would keep Control held down.

>>72
Yes, technically that's the smart thing to do. But for some reason it bothered me when I tried rebinding it and went back to C-j.

>>73
Of course you can bind your own key. You do that if it's something you do often. I can't imagine transposing words, for instance, is something you do often enough to warrant a bind; that's why you just do it naturally from lower level commands when you need it.

>>73
If you actually learned Vim I'm pretty sure you'd change in your mind.

"But you can extend Emacs to do that!" is the silliest argument you Emacsers use. If I'm going to extend Emacs to do the same stuff that Vim does I'll rather use Vim.

>>75
I've done it a number of times, but I see your point. I still think that I'd rather have it anyway for when I do need it. Having similar commands with similar bindings means that it doesn't require real effort to remember it, so I get the command for free.

>>76
You would only need to do it in the cases where emacs doesn't actually do it, it often already can. Extensibility is useful, because no one tool can do everything, or even always do it in the way you want. It's the same argument for metaprogramming, which you are probably also against.

>>76
You can extend that argument to apply to anything that has extensions(including vim) "My tool does X, I don't care if your tool can be extended to do X"

also relevant is this image from Xach, http://www.xach.com/img/lisp-and-vim.png
I think it's just part of the culture for emacsers (and lispers) to add the features they want rather than bitching about what they don't have, but I agree that it is not a compelling argument for a new user.

Why the fuck do all arguments about Emacs end up being about Lisp?

I *don't fucking care* about Lisp. Neither do 99% of developers.