I've found this handy for when you are generating HTML manuals from text comments in the source code, and you want to include a quick-n-dirty diagram in your manual.
Slightly off topic: I've recently gotten to the point where I feel comfortable and productive in Vim. I know emacs is worth the effort to learn if you're replacing most editors out there. But does anyone have any opinions on whether it's worth the effort if the editor you'd be replacing is Vim?
It really depends on what type of vim user you are. I used vi/m for 10 years before starting with emacs. Emacs works better for me. I know people for whom vim works better for them. It would be a shame not to find out for yourself.
As an Emacs user, my answer is no. Choose your path and become proficient in it. Unless you have ample time, you may run the risk of becoming a Jack of All Trades, Master of None.
Emacs is not an editor, it's an Emacs Lisp interpreter, so you can't really compare it to Vim.
If you just need an editor which is configurable no more than deemed necessary, Vim is fine. If you need more than that, Emacs is your piece of cake.
Emacs allows you to grow your own environment, which does things exactly as you wish. For instance, I've read that in Vim you can't customize where a sentence starts or ends for movement commands. Of course, in Emacs you could do that. Emacs' advantages are those shared by all Lisp environments.
Another - already mentioned - killer feature of Emacs is the ability of Emacs Lisp to talk to external processes.
This quote by Larry Clapp about him abandoning the development of a SLIME-like environment for Vim sums up the issues: "The more I worked on slim-vim, and the more I looked at Vim internals, the more I didn't like it, and the more I felt like I was just reinventing Emacs."(http://www.lispniks.com/pipermail/slim-vim/2007-May/000555.h...)
As a regular vim user who explored the emacs world for a while, I have somewhat mixed advice.
emacs is worth learning. It highlights certain features, almost all of which you can pretty much get in vim -- it is just a different focus. One feature you do NOT have in vim is the ability to smoothly run a subprocess within the editor. That is why vimmers like to call emacs an OS; however, despite the ridicule, there really is something different about the SLIME experience that you ought to feel. There has been a lot of work on emacs to make it integrate in neat graphical ways.
However, if you are fairly competent in vim, emacs is not worth using regularly for editing anything that has to do with text. The biggest issue is that to make emacs usable, you have to remap just about everything. It is almost as if its designers did everything in their power to stop people from editing text. For example (and there are many), vim folks make their lives quickly easier by using (book)marks and macros; compare the key combos for these in vim to the ones in emacs, and you will see one reason why emacs editing is, by default, slower.
I avoid remapping keys because I actually work with other people sometimes within their environment, and it helps if the keys do the same thing. This makes for an unfortunate need for me to NOT get used to dvorak. :(
There are other nitpicks, such as the inability to edit/view large files (before some naysayer shows up again to ask what large files we might edit: genome files and log files come to mind).
Also, if you are told to try viper mode (and then told subsequently to use vimpulse.el with it -- definitely do this if you are using viper), these are good suggestions to get a fraction of vim's functionality along with some minor but annoying differences. Again, I point you towards macros. But also note that as soon as, for any reason, you open another buffer (for help, for an error, for giggles), you are in emacs keys world again and not in viper, so you will not be able to do your beloved Ctrl-W Ctrl-W immediately. If you are going to try emacs, just use the emacs bindings and forget about viper/vimpulse.
One advantage suggested by emacs folks is the configurability of the editor with elisp. It is true that it is very configurable. You will find, however, that some of the difference is marketing and FUD; vimscript is a rather powerful little language worth learning in its own right. Most people do not realize that vimscript has OOP. And elisp does not teach you Lisp that you can use outside emacs... just Lispy concepts.
All that said, I am not such a hardcore vimmer that I have a "set -i vi" configuration in bash. Learning emacs helped me learn how to do edits faster on the commandline. With dual experience in these editors, I sometimes use the wrong keys (try to move forward a word with Alt-F). Fortunately, in vim, undo is just a "u" away.
Try it out. Let me know if you come away with the same experience or find ways to make it reasonably tolerable.
> vimscript is a rather powerful little language worth learning in its own right.
Yes. IMO vimscript is good enough for most tasks that come up. I would also like add that with vim there is also the option of scripting in Perl, Python, Ruby, TCL and mzscheme.
"For example (and there are many), vim folks make their lives quickly easier by using (book)marks and macros; compare the key combos for these in vim to the ones in emacs, and you will see one reason why emacs editing is, by default, slower."
Could you provide a concrete example? I'm not trolling, I never used vi but I use emacs a lot and find emacs macros very useful and powerful.
Last week I forced myself to pull a bunch of names out of HTML for a dropdown listbox using a vim macro. I could've used a regular expression but I wanted to learn vim macros. Here's what I did. No guarantees that this is the right way to do it or that it's better than emacs.
q0 (start recording a macro to store in buffer 0)
df" (delete everything from cursor through the next quote character)
f( (jump to the next open paren)
d$ (delete everything from cursor to end of line)
j (cursor down one line)
0 (skip to beginning of line)
q (finish recording macro)
50@0 (execute macro 0 fifty times)
That turned a bunch of lines that looked like
<option value="My Full Name (domain\account)">My Full Name (domain/account)</option>
into lines that just looked like
My Full Name
To reiterate, I typed q0df"f(d$j0q50@0 and my problem was solved with little thought.
(1) After the f(, you probably want h to move the cursor left onto the space before the (.
(2) Instead of d$, just use D.
Alternative for both those comments: Replace d$ with Dx
More than one way to do it anyway...
I would have spammed "qq" instead of "q0" to save finger space, but you might have already been using your q register for all I know.
The other nice thing about vim macros is that since they are stored in vim registers, they can be accessed and manipulated. Make a one-keystroke mistake in your macro? Paste it to your buffer, edit it, and copy it back into the register. Now you can use it again. Example:
"0p => df"f(d$j0q
Modify to be df"f(Dxj0q and highlight and "0y
For the readers, " accesses a register, y = yank, p = paste.
Emacs defines "yank" the opposite way of vim: it means to yank from the clipboard and paste to your buffer. In vim, it means to yank it out of your buffer and put it into your clipboard (another register, as it happens, along with special registers that understand different levels of your OS's clipboards).
> After the f(, you probably want h to move the cursor left onto the space before the (.
Or just use t( to automatically move to the preceding space. ;)
The best part about Vim is that you can ask 50 people about shotcuts and get 50 distinct answers, and each person can learn something new from each other. :)
Good catch! So true. I forgot about this point, a concept I do not see a lot of in emacs:
vim has a number of similar functions that differ purely by where the cursor ends up. The f vs t is one such distinction. Another is navigation of words by first letter or last letter (w vs e).
Not often mentioned is the variations of block highlighting, where I can quickly (two or three letters) highlight my block and choose whether or not to include the beginning and end of block. For example, when I am in the middle of a sexp, vi( highlights everything inside the parentheses, and va( includes the parentheses. For {}s, just use vi{ and va{.
And there are more options like these for saving keystrokes that, thanks to generally consistent policies, are the same for multiple commands -- cw (change the next word), dw (delete the next word), vw (highlight the next word), etc.
Thanks for the comparison. I took a few tips on Vim macros yesterday and shortened mine:
qqdf"t(D+@qq@q
qq opens a macro in register q
df" deletes through the first "
t( jumps to the character before the next (
D deletes to end of line
+ jumps to the beginning of the next line
@q recursively calls macro q
q@q stops recording macro q, calls it once
This post is actually wrong on many accounts. For example, you'll find that M-Z followed by C-s is followed by immediate disappointment. It also does not save the macro or even do what the vim macro does (going to the beginning of the next line before starting the macro), which would cause it to fail catastrophically. The real sequence (based on this one) is this:
C-x (
M-z "
C-s (
C-b
C-b
C-k
Home
Down
C-x )
C-u 50 C-x e
I did two "C-b"s. I did that as more of a way to get out of the search mode quickly and lead into the next move. The first C-b could be an enter. The second C-b could be a left arrow, saving a keystroke but taking you off the main keyboard; however, I thought it would be nice to hold down the ctrl the whole time and just double-tap the b, so I will be keeping that in mind for keystroke count. Not that this is a problem in emacs... after all, you are having to hold down ctrl or meta throughout most of the process here, so you have to make stretches.
If we count holding down the ctrl and meta keys as characters/keystrokes (and we also need to count the shift key), we have a total of 29 keystrokes.
I would not personally use the C-u combo, though, for numbers. I just held down Meta. That reduces your keystrokes to 28.
And it is 27 if you use enter and left arrow instead of C-b C-b... the fingering is more awkward and arguably slower, but it will work (as opposed to the other NOT working) if you are not in highlight search mode.
I gave all the shortcuts I knew about (not retyping ctrl in silly places, etc), but all those shift keys and finger switches add up.
With vim, you will find that you do a lot less of this song and dance with modifiers.
His improved/correct vim macro, btw, is qqdf"t(Dj0q50@q which has a total count of 18, counting smart use of the shift key. The finger stretches are a lot shorter and the feel more natural. Try both combos as listed (I am using a 28 keystroker for feel), and you should see what I mean.
qqdf"t(Dj0q50@q
C-x ( M-z " C-s ( C-b C-b C-k Home Down C-x ) M-5 M-0 C-x e
In other words, there is additional value over just number of keystrokes.
Note... if 50 was the wrong guess at the number of lines, he does not have to type @q or @0 again to recall the last macro used. He can just type @@. This makes life much easier in an uncertain wall of text.
Edit: Parbo's suggestion of using function keys (which looks like only one macro can be used at a time) brings the emacs count down a little at the expense of flying to the top of your keyboard: -6 keystrokes, leaving us with about 22. Try that for feel as well:
qqdf"t(Dj0q50@q
F3 M-z " C-s ( C-b C-b C-k Home Down F4 M-5 M-0 C-x e
Yes, there's one character missing after M-z. I used M-z > to zap to the first > (and not to " like you did). I was not trying to do the same thing vim was doing; I was aiming to get the same result.
I didn't save the macro because I never save a macro if I'm only going to use it once, and it can be saved long after you finished it, provided you don't define another macro.
Also, the number of keys in not the only factor but the distance as well. For instance, Home and Down are located very far from the home row in my keyboard, so I always use C-a and C-e (and C-n and C-p). And they are surprisingly comfortable with the Dvorak layout I use ;-)
Vim define a macro (stored in q because it is easiest, but to change the name replace the second q with any letter):
qq<do stuff>q
Emacs define a macro:
C-x ( <do stuff> C-x )
Vim do that macro again 40 times:
40@q
Emacs do that macro again 40 times:
C-u 40 C-x e
Naming a macro in Emacs (so you can have multiple) takes even more keystrokes and I'm not entirely sure on the incantation to repeat a macro from name - none of the help files seem to tell me how to do this, only to save it.
Parbo already pointed out F3 and F4 for the first part. For the second part (repeat it 40 times) you could use:
M-4 M-0 F4
Which is only 4 characters, the same as VIM.
Of course the F keys are a bit further to reach which can slow things down a bit. But it does leave it as not that great an example of the VIM being better. I'm sure there are better examples. Although I'm an Emacs user I've got learning VIM in more detail on my todo list.
Anyone? I'd like to know the emacs way to save the expression into a register. Or is there a way to cycle through expressions that were previously repeated?
Vim modal keys will always be more effective (and less painfull) to just edit raw text.
Emacs will always be more extensive because elisp, with all its problems, does great there. I also prefer how Emacs handle multiple buffers too (even with Vim's project plugins).
That said, I'm trying to use Textmate now. I think Emacs is what fucked up my left wrist.
textmate is great. If you haven't installed them yet, check out Ackmate for super awesome fuzzy search, project+ for a decent project drawer & dvcs state visualizer, and the getbundles bundle that lets you get up to date versions of bundles via github
I used Vim exclusively in the past, and as an exercise in curiosity and experimentation with Lisp' I dabbled with Emacs. Somehow, during the process of learning emacs, I gradually abandoned Vim and am using Emacs almost exclusively now (throw in odd IDE like VS and Eclipse here and there). I hadn't even realized I switched Vim for Emacs, it just happened.
I can't say I am more productive or anything with it. Probably the thing that took me away into it is that real process of learning Emacs is not actually learning any given set of commands (well, that happens too, of course), but it's more about starting to customize your own Emacs.
During that customization process, Emacs grew into something I'd use if I were to build one myself - and, to an extent, I built one myself by customizing it. So, it's like a bio-suit, it's an amorphous mass that grows around to fit you almost perfectly as you tap into it's powers.
Emacs is not just a text editor, its more like a text editing platform or framework, or something like that. Emacs is literally the lisp of the text editor world, if you have the time and patience you should learn it even if you won't use it much, for the so called enlightenment it will offer you.
You can be up and running in Emacs in a few minutes, if you grab AquaEmacs. It uses the Mac keybindings. Cmd-w, Cmd-s,Cmd-o, Cmd-c,Cmd-x,Cmd-v, etc. Just like any Mac program, navigate the menus to see what features and keybindings are available, when you get the urge.
Very cool. In Emacs.app (aka. Carbon Emacs) my right click acts as an eraser and does not show a menu like it does in the video. Does anybody know how to enable that popup menu (I am a vim user and a emacs noob.)
Vanilla windows install, same problem here. C-h m will show the documentation for the minor mode, there should be keyboard commands for everything, I'll need to spend some time on this, it looks great...
I use the lightweight emacs alternative 'zile' a lot, I have it installed on both my desktop machines (alongside emacs) and also on some tiny machines like OpenWRT routers where I don't want an emacs install.
It loads totally instantly whereas my emacs configuration is ~0.5s, so if I'm really just jumping into a file for something very simple and then out again, I use that.
One step up in complexity is to alias something as 'emacs -nw' (emacs start in console mode.) Which is almost as quick (depending on your startup files), but you've got all your nice custom .emacs configuration there.
Then, there's the fact you can run emacs in server mode and then your emacs editor windows are just connecting back to a server process and not loading up anything at all.
Finally, there's the fact that a true emacs user would already be interacting with their shell in emacs shell-mode, so they wouldn't need to load anything at all.
Traditionally one has a single, long running Emacs process that you do everything in, even quick edits. If you had to wait for it to start up from scratch then yeah, that would be pretty annoying.
My fingers frequently go `sudo vi ...' because I'm not used to using the sudo mode in TRAMP, but that would arguably be my deficiency, not Emacs.
I used to use vim for coding before switching to Emacs (well, TextMate and then Emacs). I still use vim for editing on remote machines and quick local edits. There certainly are people who edit everything in Emacs though, I'm just not one of them.
The takeaway for me (since I use Emacs in a console and not in GUI mode) is `C-x n n` and `C-x n w`. Looks like it could be pretty useful for `M-x replace-regexp` (if I don't want to use query-replace-regexp, and I've got a lot of searching and replacing to do in a particular region.
indeed. When you want to do a quick and dirty 'replace-string', this command looks very good. I've ended up copying the whole region to scratch to make my edits more than once.
If you use transient-mark-mode (which is on by default these days), you can mark a region and then use replacement commands like query-replace (M-%) that affect just that region.
