Some more comments after using emacs for a while:
(define-key ac-mode-map (kbd "M-TAB") 'auto-complete) to your .emacs, so that you can use M-TAB to force the completion menu to come up. This generally happens automatically, but I think this is the only way to get fuzzy matching, for example. Actually, you can also just use (ac-set-trigger-key "TAB"), which intelligently sets TAB to complete or indent, based on which one you more likely want. This seems to work pretty well to me.TAB repeatedly, and it cycles through all the syntactically legal indentations. I find this to be more useful than the usual TAB indents behavior of most editors. Note that by default, it won’t automatically indent, even with trivial indentations (i.e., keeping the previous indentation). This is easy to fix, though. Just add (define-key global-map (kbd "RET") 'newline-and-indent) to your .emacs file. This will make RET do the same thing as C-j, i.e., basically the equivalent of RET TAB.But unlike all the other hundreds of emacs features that I don’t use, this one was seriously slowing down my workflow. It adds three or four seconds to the startup time of emacs when loading from within a git repository. So I did some Googling and added this to my .emacs file:
;; Disable all the version control stuff ;; Makes emacs load much faster inside git repos (setq vc-handled-backends nil)
(unrelated: Why doesn’t WordPress support lisp as a language for syntax highlighting?)
This disables the version control stuff, making emacs load fast again (virtually as fast as vim, actually).
M-x byte-compile-file from within emacs. Just make sure that if you modify the .el file that you recompile the byte code, or it will continue to use the old version.
;; ===== Enable mouse support ====
(require 'xt-mouse)
(xterm-mouse-mode)
in your .emacs file. And then it just works. It needs some tweaking (e.g., it doesn’t play so well with momentum scrolling), but at least it works. I thought I was going to hang myself without mouse support. Because frankly, as good as the movement commands are, moving with the mouse is so much easier sometimes (the same is true for vim too, btw).
emacs to emacs -nw. I’m sure I just need to add some flag to configure, but I haven’t gotten around to looking it up yet.;; ===== isearch+ ===== (require 'isearch+)
and most importantly, you need to edit the file and uncomment all the commmands you want to allow. If you follow my link above, it goes to my personal dotfiles repo, where I’ve already done that.
On the other hand, with vim, I had to edit virtually every extension I installed to make it do what I want. I’m not sure what this means, though. It could be a statement about one of many things: how the emacs community provides nicer defaults, how the vim language is easier to use, and hence more inviting for me to edit the files, or how I haven’t gotten around to messing with certain things yet.
M-x customize, and reading my .emacs file. And my best advice: if you want emacs to do something, first do M-x customize and search for what you want (EDIT: apparently searching customize requires emacs 24, i.e., the development version). If you don’t find what you want there (and you will surprisingly often), search Google. There are so many emacs users, that the chances of someone else wanting what you want are very likely. I’ve found the results from the emacs wiki to be particularly helpful. And one more thing: if you find an extension you like, double check first to see if it’s not already included in emacs. Emacs seems to like including good extensions in future releases, so an older extension has a good chance of already being included.Some emacs questions:
(define-abbrev global-abbrev-table "Ondrej" "Ondřej"), so that when I type Ondrej it give me Ondřej. But it doesn’t work. Is this a bug or what? If I do (define-abbrev global-abbrev-table "foo" "bar") and type “foo”, it turns into “bar”, but the above leaves Ondrej alone. EDIT: I guess this was an emacs bug. It doesn’t seem to be there any more (perhaps it was fixed with the git version or something).M-x load-file RET ~/.emacsThis Tuesday will mark the point where I will have spend as long using emacs as I did using vim. But already, I feel more competent with emacs. I won’t repeat what I said in my last post, but I just want to say that the ability to edit and write at the same time makes me way more productive. The fact that it uses keyboard shortcuts that I’m already used to probably helps a lot too. Even so, I’ve not used any kind of cheat sheet for emacs (since I never really found any that were any good), and yet I feel like I’ve memorized more key commands now than I ever did with vim, for which I did use a cheat sheet.
So I really don’t see myself going back to vim at this point.
I’m actually surprised. Virtually everyone I know who uses a command line editor uses vim. It’s definitely the more popular of the two. But having tried both, I can only speculate as to why. Vim has a much higher learning curve than emacs. Everybody grows up learning how to write text in editors like Microsoft Word, TextEdit, Notepad, etc., that all work fundamentally like emacs: if you type text, it enters the text. If you want to do advanced editing with the keyboard, you hold down some meta keys and type chorded keyboard shortcuts. The vim modal editing methodology is so different from this, that it surprises me that so many people go to the trouble of learning it (I mean, to the point that they are more efficient with it). I can see the benefit over GUI editors, which have nothing on either vim or emacs with regards to customization, or just the plain editing power that is really necessary for coding. My guesses why people use vim:
Maybe the vim users out there could comment why they use vim. Am I missing something? Or are your heads just wired differently from mine? And if you use emacs (or anything else), I’d love to hear from you too?
At any rate, I recommend that anyone who wants to give command line editors a chance do what I did: learn both vim and emacs. My blog posts should be enough to give you some good advice. I went cold-turkey, and I recommend that you do too, but only do it if you won’t have any important editing to do for a few weeks, as your editing rate will slow down a lot as you are learning for both editors. And even though I think I am going to stick with emacs, learning vim was still valuable. Unlike emacs, vi is part of the POSIX standard, so it’s included in pretty much every UNIX distribution. I’ll be glad when I find myself on a minimal command line and know how to use a decent text editor. And anyway, you can’t really know which one will be your way until you try them both. I really thought I would end up using vim, as it was so popular among all the people I know who use command line editors. But I guess there is only One True Editor.
EDIT: I found out how to make emacs really fast. The key is to run one process of emacs in daemon mode, and have the rest connect to that. Then you only have to wait for the startup once (per computer session). To do it, just set your EDITOR to 'emacsclient -a "" -nw' (and you might also want to alias emacs to that as well). What this does is connect to the emacs daemon. The -a "" starts one if it isn’t already started (you can also do this yourself with emacs --daemon. If you only want to use the daemon version if you’ve specifically started it, replace "" with emacs. This will connect to the daemon if it’s running, and otherwise just start a new emacs process.
The -nw keeps it from running in window mode. Remove this if you use the GUI version of emacs. This is necessary to make it work correctly with multiple tabs. This is so fast that you should never really even need to use C-z to quickly exit emacs. C-x C-c is just fine, because reopening will be instantaneous. I like this because I was starting to accumulate background emacs processes that I forgot about.
This probably requires a fairly new version of emacs, possibly even the development version.
Aaron Meurer's SymPy Blog 
next time you are really bored, check out artist mode, or psychiatrist
Thanks. I knew about psychiatrist (see my first post in the series), but not artist mode. It seems that iTerm2 doesn’t support click and drag, so all I can do is created dots. I’ll have to try it in the GUI version.
Hmm, I tried it in Aquamacs, and that one also only drew dots (though it did work with dragging). I remember seeing a picture where it also drew things like \, -, and /. Am I missing something?
I started with Vim in 2009, so I haven’t been using it that long. Before that I had been using Kate in KDE for several years and Emacs before that. Prior to using Linux, I didn’t have a real text editor at all (on Windows). On OS/2 I used the Enhanced Editor that came with Warp 3 and 4, and in DOS I used the DOS editor (edit.exe).
I had tried Vim a couple of times over the years, but failed to understand it and quickly gave up on learning it. When I finally did learn it, it was because I was in need of an editor that would fit into any environment I happened to be using. At the time, KDE was undergoing major growing pains. I didn’t want to rely on it while it was so unstable, so I started hopping from one desktop environment to another and was having different text editors thrown at me by default in each one, some better, or worse, than others. I decided I needed to take control of what text editor I used and chose to learn a text-mode editor. And why not? What does a text editor need fancy graphics for, anyway? (Well, it DOES make the fonts look better.)
I had put off learning Vim for a long time and decided to dive in head first. What I would say about learning it (and its tutorial agrees with me) is to not try to memorize commands. If you are approaching it that way, you’re doing it wrong. Memorizing commands from cheat sheets is the wrong way to go about it. That’s like trying to memorize how to ride a bicycle.
When I learned Morse code for my amateur radio license exam, it was the same way. If you try to memorize dots and dashes, you’ll never get anywhere. You have to listen to the sounds and let your hand write down as letters, what your ear hears as patterns.
It is also like learning a foreign language. If you try to do it by translating what you hear into your native language in your head, you won’t learn anything. What you need to develop is muscle memory that translates what you are thinking of doing to your text into finger movements on the keyboard. It’s much more like touch-typing than anything else. And, indeed, it is suggested by several experts, Vim’s author included, that you learn touch-typing prior to learning it.
Its command set is a mini-language of text objects and actions that can be combined in infinite ways through a consistent syntax. Once you understand that and learn a little muscle memory, learning new commands becomes easier and easier, until soon you find yourself typing Vim commands in inappropriate places, like inside of word processors or on web pages.
But why bother in the first place, when there are so many easier editors to use? That’s a good question. It is one that many users have a difficult time articulating, and it has to do with efficiency and an almost Zen-like experience while using it. Some describe becoming one with the editor.
I believe it has to do with the way in which Vim encourages efficiency. Most user interfaces place their efficiency at the software end of the user interface, in menus and other devices for issuing commands, but give little thought to the physical actions required of the user to command the software. In a text editor one’s hands are on the keyboard when typing text. But issuing commands almost always requires either moving the hands away from that position to press chords or to manipulate the mouse. It’s a safe bet that you’ll have to divert your eyes from the text on screen to do those things, too. It jars your concentration.
Vim’s interface is designed with efficient physical motion in mind. Commands are typed just like text is: by touch-typing. It’s commands can by typed without looking at the keyboard for this reason. Not needing to look away from the text helps keep you from losing your place while you run some command or other. Vim’s user interface keeps your hands touch-typing and keeps your eyes on the screen. This promotes deeper concentration. Thus, the Zen-like experience reported by some users.
Another reason to learn it is that it enables actions on text that requires the addition of new commands or custom macros in other editors. If you wanted a command that deletes an arbitrary, but specific, number of paragraphs, many other editors would need a macro or additional commands. It wouldn’t be possible in some editors at all. But in Vim there is no need for such a macro: 5d} does it five times, or 100d} does it a hundred times. If I don’t like doing it that way, I can also do it like this d5} or d100}, depending on how I like to think. Remembering how to do it is not about memorizing dee five right-curly-brace. Its more like left index finger to the five key, left middle finger down, right pinky up to the right while pressing shift. It’s a touch-typing memory thing, not a string of characters thing.
It’s very difficult to articulate why Vim is worthwhile to learn, but it is near impossible to convince anyone if they insist on learning it through memorization from cheat sheets. Those efforts are almost guaranteed to fail with the result being someone who gave Vim a fair trial and decided it was not for them. The frustration I feel when someone does that drives me crazy, because it would all be so much easier for them if they would only take the advice that is given to them.
:wq
Thanks for the write up. I’ve heard similar accounts about a “Zen experience” when using vim. I think you can get the same thing in anything that uses just the keyboard, such as emacs or even just the bash shell. This is why one of the more annoying thing about emacs to me is the lack of type-ahead support while it’s booting up.
I’m a little confused about what you actually suggest doing with respect to cheat sheets. I used a cheat sheet to learn because it would be impossible to do so otherwise. If I just went off of what I remembered from the tutorial from the start, I would end up just editing with nothing but h, j, k, l, and i, which would extremely painful (I can be more efficient in nano). I think you have to agree that you need some kind of reference to learn the basic key commands when you start. A cheat sheet is probably the best way to do this, as it gives you only the information you need.
In my experience, when you learn something like this, you first learn it by rote (or you always look it up). Then, if you use it often enough, you will gain a muscle memory. It’s not because this is the best way to do it; I simply don’t see how else it could be done. How do you go about gaining a muscle memory without learning some other way first? You can’t learn a language by reading text in that language until you “get” it. You have to learn at least some base vocabulary first.
I do agree that muscle memory is the way to go. This is the only way that you can be as fast as you want to be. Touch typing is a perfect example of this. There is a limit, a pretty low one, to the wpm that you can achieve without a muscle memory of the keyboard. But you’re saying something equivalent to saying that the best way to learn how to touch type is to buy a keyboard that has no letters on the keys. This may actually work well for someone who is close to being a touch typist, but I’m pretty sure it would result in a slower learning rate for someone who’s never typed at all before.
Maybe I’m misunderstanding what you’re saying, and we really do agree after all. I don’t feel that the reason I chose emacs over vim is that I used a cheat sheet, however. For one thing, you need to learn a bunch of key commands for emacs too. I actually haven’t been using a cheat sheet for emacs, as I noted. But I feel like this has made me less efficient. This is because the cheat sheet serves as a constant reminder of more advanced keyboard shortcuts, which you would otherwise forget about and never use. For example, I just recently was reminded of the M-a and M-e keyboard shortcuts in emacs.
Finally, an unrelated note: I never really got the hang of numbered command, either in vim or emacs. To me, by the time you count exactly how many words you want to delete (or whatever), you could have just pressed the shortcut that many times. You can guess, but you’ll end up getting it wrong most of the time, and for destructive commands like delete, you’ll end up underestimating every time, again making things less efficient in the long run. I actually rebound C-u in emacs to work like it does in bash, because I never use this feature. Do you just get really good at estimating the number from sight, or what?
I don’t mean to totally forgo cheat sheets. What I mean is that you should not rely solely on rote and definitely not on remembering the commands as strings of characters but to learn them as finger movements, so that you are not constantly doing something like this in your head: “OK, I want to delete a sentence. Let’s see, that’s either das or d).” You want to get to the point where you are thinking delete a sentence and your fingers just do it. Probably, what many people do is try to remember too much in the beginning and get overwhelmed. I would say, don’t add new commands until you develop muscle memory for the ones you’ve already covered. I’m not totally against cheat sheets, but I do think it is better to make your own consisting of only the commands you have not mastered yet, but need right now.
Tutorials for learning Morse code work this way. They start out with the simplest of sounds and add similar ones gradually, but only after you master the current material. Eventually, you are listening to the entire alphabet and other symbols and increasing your speed at copying code.
If I were to give someone advice for learning Vim, I would tell them to practice the movement of their fingers for the commands they are trying to learn and try to remember what it feels like to issue particular commands. I have had better success learning new commands that way than by trying to remember that gf opens the file name under the cursor or that gg=G reformats my file. I find that sometimes my fingers do it before I am able to mentally recall the keystrokes, and I have to think about what I did to translate it into a string a characters in order to tell someone about the command.
:wq
The counting problem, how many words am I trying to delete, or whatever, I totally agree with you about. I don’t have a knack for quickly counting how many words are in the text, either. I tend to use visual mode for those situations. I just type v, followed by word movement or other movement commands, to extend the highlight until it covers the text I want to change. Then issue the command: d, c, y, or whatever.
:wq
I learned emacs for org-mode, but have contemplated learning vim simply because I like to try new things and am always wondering what the best tool is. Having gone through the learning curve of emacs, I’m not thrilled about doing so, but was googling around for comparisons just to see… which brought me to this post.
Having read your response, I think that as Aaron mentions, this type of reflex is possible with anything physical. I’m assuming you aren’t suggesting that only vim commands allow one to be “Zen like” in their movements?
I export a lot in orgmode as I tweak LaTeX files. =C-x C-s C-e p= is unbelievable reflexive. I don’t look. It just happens. C-x C-s and C-x C-f are as well. Sure, these are damn simple; I’m simply illustrating that people can and do learn to adapt to any environment in this way and it becomes part of them. I think “browser” and my fingers to Ctrl+Alt+i, as that’s what I have openbox bound to… so much so that when I’m using Windows and think “browser” I do the same thing.
“Having read your response, I think that as Aaron mentions, this type of reflex is possible with anything physical. I’m assuming you aren’t suggesting that only vim commands allow one to be “Zen like” in their movements?”
I don’t think the commands themselves enable a Zen-like experience; It is the ability to issue commands without diverting your eyes from the screen or having to move your hands from the keyboard that promotes the Zen-like experience, regardless of the command set.
Wordstar still has devoted users for the same reason. See “WordStar: A Writer’s Word Processor” by Robert J. Sawyer at http://www.sfwriter.com/wordstar.htm for a similar explanation of this kind of experience from using that program. In particular he writes, “[T]ouch-typists find that using the WordStar control-key commands is much more efficient, because they can be typed from the home row without hunting for special keys elsewhere on the keyboard.” This lets you maintain most of your concentration on the text. If Emacs enables that, then sure, this would apply to that editor, too.
I don’t agree that any and all user interfaces promote this kind of experience. Some clearly do not. The less the software gets between you and concentrating on the text, the better. But as soon as the interface asks you to fully divert your attention from the text and give it to the program to perform some action, that Zen-like concentration is broken. Mouse-based interfaces using tool bars and pull-down menus fall into this category. They cannot be used without diverting your eyes from the text. A select few programs give top billing to the data; Most upstage it, calling attention to themselves as if they are more important than what you are working on. I’m thinking of programs like Microsoft Word or PowerPoint, though a large number of text editors are guilty of this. They almost seem to be crying out, “Look at me! I’m so cool!” When I have to use them, I feel like the point of using them is to gawk at their awesomeness.
:wq
I think I agree with this. Surely not all user interfaces are equal. That’s why so much care must be taken when designing them. But you can’t bash other interfaces in and of themselves: they are clearly designed for different audiences. Word is designed for people who not only cannot touch type, but cannot remember a single keyboard shortcut (if you’ve ever watched someone do a copy and paste entirely with the mouse, you know what I’m talking about). Word also attempts to fit the needs of more advanced audiences by allowing to set custom shortcuts in a very advanced way. If course, that editor is not even on consideration here, because it is not a code editor.
One thing I like about emacs over vim is that it manages to combine a helpful interface on top of the “zen” one. For example, if you don’t know the shortcut for a command, M-x command gives it to you. And the command names are verbose enough that you can often guess what they are. And if you run a command and there is a shortcut for it, it tells you in the echo area. This is how I learned about the M-= shortcut to do a word count. The emacs menu system also helps to learn new commands In vim, the command names tend to be abbreviations that are hard to guess at, and I don’t recall it telling me about shortcuts afterword (but I could be wrong about that).
To answer the main question, I definitely find emacs shortcuts to be “zen-like”. I find C-x C-s C-x C-c to be even faster to type than :wq (mostly because I don’t have to worry about removing my finger from the Shift key at just the right moment). emacs helps with muscle memory by making C-letter and M-letter do similar things, so your fingers don’t have to remember different locations on the keyboard.
“In vim, the command names tend to be abbreviations that are hard to guess at”
The commands are hard for whom? That’s what the help system is for and why it consists of two book-length references. Users who want to succeed just have to be willing to learn to use it.
“[Y]ou can’t bash other interfaces in and of themselves: they are clearly designed for different audiences.”
I don’t think I am. I was referring specifically to how mouse-based interfaces that use tool bars and pull-down menus do not promote a Zen-like experience and call attention to themselves. Word and PowerPoint were only examples of this type of interface. I could as easily have used code editors as examples. On my platform, the obvious choices would be Gedit and Kate. On Windows, Notepad++ is an obvious example. On OS X, Textmate comes to mind. There are more code editors that use this type of interface than code editors that don’t. Check out the editor index at Text Editors Wiki http://texteditors.org/cgi-bin/wiki.pl?EditorIndex to see just how many there are. They may compensate for this in various ways, but that doesn’t change my point. And just to be clear, I’m also not suggesting that these code editors cannot be used with the keyboard. What I’m saying is that the point-and-click portion of the interface does not promote concentration; Rather, it interrupts concentration.
I’m also not suggesting that mouse-based interfaces have no place or that they are wrong in some way. They are perfect for those that don’t want to use the keyboard or remember commands. But I stand by the position that they do not promote good concentration and that they are less efficient when used with the mouse.
:wq
[…] Vim vs. Emacs (Part 3) « Aaron Meurer’s SymPy Blog. Like this:LikeBe the first to like this post. […]
It’s definitely this one: 5). Brain’s wired differently.
I was about halfway through the vimtutor when I fell in love with Vim, and I’ve only grown more keen on it the longer I’ve used it.
To me, the modal interface makes editing text like a game; it is literally fun for me. Whereas you find it a pain to have to press Esc all the time. This guy hit’s the nail on the head: http://robots.thoughtbot.com/post/13164810557/the-vim-learning-curve-is-a-myth
I can see where you’re coming from. My friend (a vim user) told me once about some vim game where you are given two blocks of text, one before and one after. The game is to change one into another using the fewest number of vim commands. I never really found this, but I’m sure that that sort of things would have helped me become more efficient in vim.
But for me, sitting there trying to figure out how to “efficiently” do an operation, I could do it faster by just the slow way, because I don’t lose any time on thought. There’s also probably many things that could be said about perceived time and the effect of that when I have to think about how to do an editing command and when it’s just done. Scott’s concept of muscle memory also comes into play here.
The point is, when I was learning vim, I found myself just arrowing over do to something rather than using the faster keys, because it felt faster than trying to remember (or lookup) the keys to do what I want, not to mention trying to figure out the correct sequence of them and so on.
An interesting note: if I ever found myself doing serious editing on my iPhone, I might consider using vim (or viper mode), because there, typing is very painful, especially chorded commands (this depends on how the editor implements them, but I’ve yet to see something that is highly efficient). Then I would just need a big “ESC” key somewhere, and I could do the rest with the regular keyboard.
It’s true that *before* you get the hang of Vim, you can often do things faster by just (say) hammering on the arrow keys.
The point is, though, that once you *do* get the hang of Vim, the “efficient” method requires no more thought than the inefficient method. When I’m editing in Vim, I don’t sit around thinking about figuring out how to do things “efficiently”. Those methods are already ingrained in my fingers, and they just happen.
And once you get there (which doesn’t take as much practice as you might think) you find editing in Vim joyful and extremely efficient.
Again, I’m not trying to convince *you* that *you* should be using Vim. I’m just trying to explain why those of us that do love it so much.
The game your friend told you about is Vim Golf, and it shows off the potential of Vim.
For example, take this challenge: http://vimgolf.com/challenges/4d1a34ccfa85f32065000004
If you were good enough at Vim, you could convert the “start file” into the “end file” (and save the file and quit Vim) in *literally* the same time it takes me to type: efficient vim
Yes, it’s impossible to be able to know how to complete all the challenges in Vim Golf as fast as you can type the commands, but even getting *vaguely* close to that is an enticing goal!
I started with Emacs (well over 10 years ago now…), it worked pretty well for me. I didn’t like the key combinations, but I figured well, that’s the way it is. Then my friend recommended me to learn Vim, so I did (from the tutorial). It took a while to get used to hjkl. As Scott says above, I never used any cheat sheet. I just picked up the basic commands whenever I needed it. It took some time to get used to it, but I would consider the learning curve about the same for both Vim and Emacs (from my own experience).
After using Vim for about 10 years now, I am more effective in it than in anything else. I think it’s philosophy is the right one.
Interesting. I’m curious to what degree you customized each editor. Did you make many modifications in your .emacs/.vimrc files, or did you mostly just use the defaults?
Hi, I just wanted to put my few thoughts. I know both editors. But I like emacs more than double-standard (double-mode) vim. Although whatever suits you can be customized to any level. Just depends on you. Pick one and master it.
Thanks
Badar
Open source web developer
not sure if I am not doing it right, but xt-mouse (or ext-mode) is not working fully with emacs 24 on my debian sid box (only able to move vertical frame partitions)… trying to give emacs a fair shot, but it is hard (why are so many of the default confs so far from usable?)
I actually still have issues with mouse reporting, which I haven’t gotten around to fixing.
I agree about the defaults. Vim is the same in my opinion. At least emacs has the very friendly M-x customize to change the most common thing. For more advanced stuff, just Google, and you’ll find someone else who’s had the same problem and has posted a solution.
Also take a look at my .emacs file (see post for link). There’s a lot of useful configurations there.
“Maybe the vim users out there could comment why they use vim.”
I guess the systems I used in the past (at university or the Linux distributions I tried at home) simply had better defaults for Vim than Emacs. For example:
With Vim I could use Backspace and Delete, while Pico and Emacs had problems with one of those keys (I do use Vim with the arrows, home, end, delete, etc. I use the “native” Vi commands too, but only when they improve my productivity)
– Backspace opened help in Emacs.
– Save (C-x C-s) or search (C-s) froze the terminal.
– In Vim I could get syntax hiliting and autoindenting for every programming language I could imagine, with little configuration (I just copied vimrc_example to my home dir).
– In Emacs Enter does not repeat the indentation of the previous line by default (am I in Notepad??), while Vim intelligently (un)indented every line according to the previous one, handling braces and everything else much better than any other editor I had tried.
– The instructions of Emacs did not teach how to open a new file without giving it a name. These little things add up.
It’s true that after the first impression I had to adjust several little annoyances in Vim (I still don’t use it much for free text, only for programming), but I was already hooked. It’s also true that changing just a few settings, Emacs does everything, but in my first tries of Emacs it simply didn’t work. Now i’m trying it again, after a few years, just for fun.
Actually, I’ve been using a Linux box for a little while, and I’m starting to get an idea of what you’re talking about. None of the shortcuts that require Control-Shift seem to work (I’m using Konsole in Ubuntu), which includes several that I rely on a lot. Also, Alt did not work at all in Gnome terminal (one of the reasons I switched to Konsole), and it seems to like to open the Gnome search thing instead of doing the keyboard shortcut, which is really annoying. Maybe I should just suck it up and use the GUI version until I get back to a Mac again.
Since you’re using the development version of Emacs, you might like Emacs-prelude (https://github.com/bbatsov/prelude), a nice set of customizations for Emacs. In particular, it adds more modes for various languages, includes the nice Zenburn theme by default, enables ido-mode (which makes commands like C-x C-f much nicer), and so on.
I think I may already be too far town the configuration rabbit hole to use that (I’ve even already created my own theme), but I’ll look at it to see if there are any interesting things I can carry over. ido-mode already seems like a pretty cool addition to my workflow.
It has been a while since you started using Emacs. I’m just curious. How is your experience so far now that you have more experience and a more complete configuration?
I started writing up a reply, but then it got so long that I figured that it would be best put in a new post. So I’ll reply there.
[…] my final post about my switching to Emacs, a commenter, Scott, asked me, “It has been a while since you […]
[…] using them to do true editing work. My experiences are chronicled in my blog posts (parts 1, 2, 3, and 7 months later follow […]
I actually did the opposite of yourself. I used emacs for years and then switched to vim. I actually switched because I watched a few of the people I worked with edit text with it and was boggled. A few keystrokes and things move and warp and change and humpf.. guess I need to figure that out.
I’ve used it for years now and it really does become very intuitive. The basic commands for jumping to characters in a line, changing to some other character and so on just make it super fast and easy. eg if you want to change some function arguments you can f( to find the first open brace and then ct) to change to the closing brace, insert new text and you’re done. Oh, you need to change that again on the next call? move there and press . It’s really just the flow that gets you and you really can just edit text faster.
Now, that all said.. I could go back to emacs if I installed evil or viper.. I’m sure that would work just fine for me after some learning of the customization. I will say though that the modern vim plugins are becoming amazing. Especially the work of Shougo is IMO propelling vim to the modern era with async execution, vimshell, Unite etc.
Emacs is much better as an application, it has asynchronous processing, more easily extendable. But vim is better in terms of pure text editing.
Most modern text editors basically take the Emacs approach: we’re going to have lots of keyboard shorcuts for various useful things. That’s fine, you can do some good editing that way no doubt.
Vim’s approach however, is it composing individual parts into commands. And it’s just more powerful. Emacs has a vocabulary of sentences, and it gives you easy access to the most important ones ” Delete this line”. “Delete this word”. More complicated sentences have to be looked up manually, “Delete last paragraph”. You can copy this sentence out of the dictionary and put it in your pocket (bind it to a shortcut), but your pocket only holds so many scraps of paper, and your keyboard and memory only can have so many shorcuts.
Vim does something pretty radical: it gives you words, not sentences. You construct the sentences yourself. If I have ten verbs (operators) and ten adverbs (motions), I have 100 distinct actions. If I add subjects (registers), adjectives (a count)… You can easily see that you get more sentences then you will ever have in emacs. You can also see that every time you learn a new word, you learn many new sentences. That means that mutating your vocabulary is much more beneficial.
Finally, at a practical level: while vim is not as good as emacs as an application, vim does lend itself much better to embedding than emacs, and in fact most IDEs have pretty decent vim emulators. That, combined with the fact that the most powerful facilities for operating on many languages (including python) are not found in emacs or vim but rather in IDEs like PyCharm, means that you can have the best of all worlds by using vim embedded in pycharm, and the best of neither by using emacs.