Emacs, artist mode
cinsk.org
cinsk.org
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.
I imagine on Windows you can find one with equivalent key-bindings.
As you get the urge to learn more, start reading blogs, etc.
Here's a good place to start:
http://stackoverflow.com/questions/60367/the-single-most-use...
That said, I'm trying to use Textmate now. I think Emacs is what fucked up my left wrist.
this blog post has a nice set of links to the tools in question: http://al3x.net/2008/12/03/how-i-use-textmate.html
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.
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.
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.M-x name-last-kbd-macro
which will bind the last macro you defined into a named function for the rest of the session.
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.
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 "0yFor 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).
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. :)
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.
Cool. The same thing can be accomplished in emacs with something like:
C-x (
M-z
C-s
(
C-b
C-k
C-u 50 C-x e
It's 19 characters against yours 16. And it can be reduced if you use F3 and F4, like someone noted. And, naturally, you can also edit emacs macros 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 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 mm - the cursor position is now known as mark "m"
`m - return us to the cursor position named "m"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.
E.g. http://vimdoc.sourceforge.net/htmldoc/if_pyth.html#python
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.
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...)
Especially integration with Ido mode.
When I'm setting up / configuring Linux boxes at work I always use Vim because it's always there and light weight.
I always got the impression using Emacs for this would be the equal of using Visual Studio or Eclipse.
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.
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.
Zen moment
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.
Thanks ramen!
(vim user, but emacs seems nicer and nicer every time I see stuff like this)