Emacs FAIL
Okay, no. I gave it a try for a good week. And by the end of the week, I don’t have any way to change basic stuff like fonts or colours, completion is still a mystery, line numbers are buggy, and I’ve not yet seen one single function that made me say “y’know, it’s a pain, but it’s worth it”. I wound up getting not one extra page added to the RCMS project during the entire week because of emacs configuration hell. Frac that for a game of soldiers.
I’ll stick with vim 7. Completion? Got it. Reformatting code? Got it. Testing code syntax in the editor? Got it.
And now, on with the actual work. Y’know, the thing we’re meant to use the editor for in the first place?
Right, so why even try? If you’re so happy with vim it’s clearly the right tool for you. There is no point in trying a new tool and then dismissing it because you have to learn new things.
I wouldn’t normally bother to comment, but it annoys me when people put out negative vibes about the hard work of hundreds of developers while simultaneously adding exactly nothing to the public debate and providing no useful information to anyone on the topic.
Mark Dennehy – FAIL.
I already explained why I was trying, here. This post’s a follow-up. And if you think that pointing out a problem explicitly isn’t contributing, then you’re not much use yourself.
> And if you think that pointing out a problem explicitly isn’t contributing, then you’re not much use yourself.
Well, I wouldn’t exactly call your post “pointing out a problem explicitly.” What version did you try? What did you do to try changing fonts and colors? Did you try Tools->Color Themes (Emacs 22)? What were you attempting to do with line numbers? I use line-number-mode (along with column-number-mode) and it’s certainly not “buggy” – it just works as you’d expect. What did you find buggy about it? And there wasn’t one function that impressed you enough to consider Emacs useful? keyboard macros? M-x shell? picture-mode? org-mode? ispell? ido completion? sql-mode?
These are all things I use everyday which – for me – make Emacs a very productive environment. While I didn’t learn them all in my first week of Emacs, I’m surprised that anyone that gave Emacs a fair shake for a full week wouldn’t have discovered _some_ of these features.
It sounds like you went into your experiment with the goal of convincing yourself that you should stick with Vim. That’s fine – but don’t try and sell it like you did a thorough bake-off between the two editors and you objectively concluded that Emacs is not up to the challenge.
Again, You’re not reading the earlier post where I detailed what I was doing and the problems I was having.
To change fonts and colors, I tried using a menu – didn’t work (sorry, but listing off three or four fonts on a system with fifty or sixty is a fail). I tried digging through the Emacs Wiki and eventually managed to get a font I could work with, but was still stuck having to select it in my .emacs file. I don’t care how much of a wizard you are, selecting fonts is not something you do every day, so sticking it in an idiot’s interface like a menu is a good design choice, not a personal failing. The same argument goes for colors – I’ll grant you that you can pick some out using the menu, but you’re limited to whatever was in the emacs package. Adding in new color themes (like zenburn) means, again, playing with the .emacs file. In vim, you download a file to the right directory and it’s automatically hauled up and available to choose from. I’ll save my muscle memory for things I do every day, thanks.
Line numbering isn’t a straight built-in. That’s a design flaw right off the bat for a programmers editor. End of discussion. Linum.el, found after digging through the Emacs Wiki and installed after yet more .emacs fun, doesn’t work right because it won’t number new lines until after you finish typing them. Look, if I hit enter at the end of line 10, I’m now on line 11. NOT line blank, thanks.
And no, there wasn’t one feature I found that made me think emacs was worth having to learn lisp in order to make it usable as an editor. Keyboard macros? Have ’em in vim. M-x shell? Have it in vim for simple one-liners, and we’ve got C-z as well as emacs does for more complex stuff, thanks. Picture-mode? In a programming editor? Nope, not useful, cheers. org-mode? Have it in vim. ispell? Have it in vim. ido completion? Have it in vim (look up C-x mode). SQL mode? Have it in vim.
And here’s the point you’re missing. In a full week of using emacs as my only editor, I couldn’t get the damn thing to let me edit. I don’t care if six months of training in a high mountain retreat under a kung fu master will let me edit stuff 50% faster than I can do right now in Vim. The point is that it’s a text editor. It’s not a feckin’ way of life! EDIT TEXT ALREADY!!!
Sheesh.
Yes I read your previous post as well. The point is, you started it with good goals and the nature of your second post totally undermines the good intent. If you point out specific reasons why it was hard to solve the goals you set out to achieve, then fine, I can accept that. Instead you’ve basically written a short piece, under a very provocative title implying that the software is poor. This is not a constructive thing to do, many people will read this post in isolation and it won’t help anyone except increase the smugness of a few vi users.
Sorry if my first post was a little aggressive, I was simply angered by your style of writing. If you post this stuff in public people are going to comment!
I don’t mind the comments.
And I didn’t expect I’d be as fast in emacs as I am in vim by the end of the first month, let alone the first week, but I *did* expect I could be up to notepad-like levels at least.
But I can’t set the font to something readable without playing about with snapshot releases, multiple installs, segmentation faults and eventually accepting a font I could live with rather than one I normally work with. And colours, while not as bad, are the same story – stuck with something I can live with rather than the better solution I’m used to (and even there, it’s .emacs time again).
That sounds petty, I know, but it’s a programmers editor meaning I’m staring at this thing for hours at a time – how it looks isn’t trivial, it contributes to strain. It’s important. And if vim can do it, I see no reason emacs (which has an equivalent-sized development team and far more flexibility) can’t.
If I ignore (somehow) how what I’m looking at looks like, and focus instead on editing (and again, that’s ignoring something quite important), there’s just not much in emacs I could find that justifies the learning curve (and nothing that wasn’t in vim already). Maybe if I was starting from scratch and knew no editor at all, I might have better luck – but I know of no programmer or student who hits emacs before *any* other editor.
What’s needed here (and here’s the constructive suggestion you’re thinking of) is something like Cream for Emacs. A simple, one-step install of a pre-customised emacs environment set up with sane defaults. (And I don’t mean viper, I mean pre-set colors and such, everything smoothed out, and basicly ready to code).
I suspect your attempt to use Emacs was doomed from the start, as you were looking for a better VI. Nope, emacs is no such thing.
For example, let’s look at your line numbering trouble. With VI, line numbers are very important. You pass them to editor’s commands. You use them to locate compiler errors. You give them to GDB to set breakpoints.
In emacs, the need to know line number is extremely rare. The editor commands work on the current region. The compilation and grep happen inside emacs and you can go around compilation errors and grep results with esc~. Debugger can be used from inside too, with source-level debugging mode. What else do you use line numbers for? How many lines in a range? There is a command for that, although I don’t use it. Go down five lines? ctrl-u 5 ctrl-n . And if occasionally you do need to go to particular line, there is esc-x goto-line.
Now let’s consider autocompletiion. Forget language-oriented stuff. Use esc-/. This is the supreme king of all autocompletion. It picks words for you from the files you already have opened in your editor. Amazingly useful! That is one feature that I would never, ever give up. Emacs is worth learning just for that thing alone, especially if you are into long variable names 🙂
Well Mike, I think if you’d posted your last comment as the original blog post we’d all have been much happier. The sad truth for me is that I probably wouldn’t have even commented on it, but still..
The line-numbering point’s a good one Arkadiy, but if you’re working on a PHP project (as I was for the purposes of this), you tend to get back error messages with line numbers in them. And esc-x goto-line might work, but having the line numbers there is just faster.
Autocompletion and esc-/ yup, very useful – which is why vim has C-X C-] (if you just want to stick to the tags) or C-X C-O, which do the same thing.
I happen to be working on Perl script now, which puts me much in the same situation as your PHP one. So I bound ctrl-x ctrl-l to goto-line, and it sped things up a bit.
When I was doing my attempt to get accustomed to VI (similar to your emacs foray, I guess, and similarly unsuccesful), I learned about c-x c-o. It is subtly different from esc-/, probably in the way it iterates through available completions. I find the emacs one more fluent? intutive? matching my thinking? But I guess it’s a personal thing.
Key-binding won’t speed up visual acquisition of the correct line though arkadiy, which is what line numbering speeds up.
I think the completion might be a personal thing – but again, it’s something that “Cream for Emacs” would have already set up. Myself, I’m happy to bind C-X C-] to C-] and go through the tags, I don’t even use C-X C-O that often.
If it works for you, wonderful – but that wasn’t the problem I was facing, which was that the learning curve is too steep for a beginning user who has any work to get done!
More emacs tips you’ll never need–
If you’re getting your line number errors in an emacs buffer, then C-x ` (backtick) from the error buffer does a goto-line in the appropriate source buffer. I know this works with gcc and msvc compiler errors, perl errors from use strict, etc. So it probably works reasonably well if you are running command-line php from within emacs (e.g., by using it as the compile command for M-x compile, or via M-x shell).
If you’re using XEmacs, you can get line numbers trivially by doing M-x setnu — which will autoload and run setnu-mode. Speed will suffer on truly enormous source buffers, though.
Arkadiy:
Your comment could almost be an advertisement for vi, if you just changed the editor name and the commands. In vi, as with Emacs, it seems, we don’t use absolute line numbers much, but do use relative line numbers a fair amount. Of course, we don’t type “ctrl-u 5 ctrl-n” (five keystrokes), we just type “5j” (two keystrokes). Or, more frequently, we work in paragraphs, such as “3d}” to delete the following three paragraphs. And completion? The default completion in vim is “Esc-/” style, where it uses words from other files you’re editing (which actually works a lot better for me than completion based on API lookup).
People will argue about this, of course, but I think that vi wins when it comes to moving around and doing common actions with a minimal number of keystrokes and using keys close to the home row. On the other hand, if you want to program your editor to do something, I’d say that Emacs wins hands-down.
This is not a failing of Emacs itself, of course, but I’ve noticed that vi users, in general, tend to be pretty skilled with their editor, whereas a great proportion of Emacs users are very clumsy and inefficient with it. (They still use the arrow keys, they don’t use counts [Ctrl-U], they don’t use word and paragraph movement and selection, etc.)
That said, as a multi-decade (and thus now *very* hard-core) vi user, I’m still split on whether one would want to tell a new programmer to learn Emacs or vi.
Changing the font is easy:
1. Options -> Set Default Fonts.
2. Pick a font from a bog-standard GTK font dialog
3. Options -> Save Options
I’m surprised you could do so much bitching about it.
Try installing a “Basic GNU emacs setup” in Ubuntu or Debian sometime. There’s no WIMP GUI with menubars, it’s disabled by default and you have to dig through a few manpages and experiment before finding the fastest way to turn it back on is to turn everything else off with -Q on startup. Not a good solution. And I didn’t find it till a month after giving up.
The default emacs23 packages in Debian testing and Ubuntu Karmic are GTK builds.
Not sure you read me correctly. The default install disables the WIMP interface and until you dig through a few manpages and config files can you un-disable them.
That is surprising. That means Debian or Ubuntu are fucking up the default Emacs configuration, for some reason. The upstream sources turn on menu-bars and tool-bars by default. Maybe you should file a bug report.
I’m on the tail end of five 18-hour days in crunch mode for a demo. Filing distro bug reports on an aesthetic/usability issue for an editor I don’t use is somewhat low on my list of prioritised tasks right now. But don’t let me stop you filing one…