Emacs and Vim
martinklepsch.org
martinklepsch.org
And for package management there's vundle, neobundle, and pathogen. And after my recent discovery of vimproc, I'm now motivated to resume writing plugins!
It's a good idea to use evil-mode only in code/text buffers and stay out of it when using e.g. GUD debugging. This, unfortunately, means that you're going to have to learn two sets of keybindings, the vanilla emacs ones and vim keys.
Command: move down one line
What vi uses: j
What the emacs tutorial suggests: C-n
What I use in emacs: the down arrow
I've heard a lot of people talk about keeping their fingers on the home row, and I more or less do that when I'm typing text like this, but for general navigation? I've sat next to a number of people who do it, and I get around my editor faster than they do. Based on this anecdotal evidence, I don't think moving my hand a short distance to reach another key is a significant speed cost.
(Each C-u is a power of 4. You can specify any number by typing it after the C-u, for example C-u 100 C-n to move down 100 lines.)
Sometimes I want to make a complicated motion in the horizontal and vertical axes at the same time in a context which is not well-formatted source code and hence has no good paragraph/word landing points. For this I move my hand slightly further and grab the mouse. It always amuses me watching people try to do it "the right way" and then spend 30 seconds trying to work out what sequence of buttons will get them there, then spend another 30 seconds remembering what they wanted to do when they got there.
I'm not trying to minimise the number of logical keystrokes, I'm trying to minimise the time and distraction of navigation. A few simple operations combined with key repeat seems to work really well. Lots of people seem to neglect the power offered by key repeat.
I'd love to meet somebody who could navigate source code faster than me and learn how they do it. When I do, I'll probably change my approach. However, I've worked with a lot of different people who used a lot of different approaches (yes, including that one where you display the line offset from point and type the number of every jump) and in the past decade I have not found any of them to be faster than me - although I have found a few who were roughly the same speed.
I'm sure something like this is possible in Emacs, but in vim I have it set up so that my current line shows the absolute line number and other lines show the relative line number.
If I'm eyeing a particular line that I want to jump to, I just read off its relative line number and hit j or k, according to whether it's down or up from where I'm at -- I'm there. Because I use relative line numbers, the number is never more than two digits.
For more precise navigation (jumping to a particular spot on a particular line), I use a plugin called EasyMotion, which basically lets me jump to any text object on the screen with a few key strokes.
I remap it to Caps Lock of course.
I keep escape as escape as well. Capslock is absolutely worthless to me.
These sort of systems are a great way to remap keys; I wish such remapping was exposed by operating systems in a nice stock way.
Then the strongest defenders of emacs tell you that you must use whatever you want because the purpose of emacs is that the editor must adapt to you and not the opposite.
Is constantly hitting the Escape key (even remapped to Caps Lock, or using ^[) really any better on your pinky?
Now, if I ssh between different unix box a lot without the time to pull my .vimrc from github, then I still have to resort to pinky-escape.
Personally, though, I don't find the worst strain comes from the placement of Ctrl. The worst comes from the awful staggered layout of keyboards that serves no purpose save for a long chain of HCI backwards compatibility with the typewriter. I hope someday keyboards like the TEK (which, incidentally, gives a perfect spot for Alt or Ctrl under the left thumb) become more commonplace, or eye movement-based systems supplant the use of one's hands for focus control.
For example, moving forward a character is C-f, moving forward a word is M-f, and moving a balanced expression forward is C-M-f. Same with b for backwards movement. C-a moves to the previous beginning-of-line, C-e to the next end-of-line. M-a and M-e do the same with statements in place of lines.
I can't even remember at this point how much of this is standard, but I've replicated the forward/backward movement for killing: C-d deletes a character forward, M-d kills a word, and C-M-d an expression. C-h deletes a character backward. Guess what M-h and C-M-h do.
Of course, both editors let you do basically whatever you want, so really the text input issue is just one of whether you prefer chording or modal input. And I'm not saying modal input isn't useful; Magit's input system is closer to vim's than to the rest of Emacs, as is Ediff's, and I like it that way, but I prefer chords for editing -- less state to hold in my head.
Sequential chords, though, like C-c C-v C-d, are right out, and using C-n and C-p and co. for up and down sucks, especially when I try to use M-p to select the last input in minibuffer history and hit M-o instead, prompting me to select Bold, Italic, or Other. I'll change them eventually; the hardest part is deciding what to replace them with.
/aimlessramble. I guess it all just boils down to "Use the tool you can best configure to work the way _you_ want it to." I think the linked article was trying to make the case that Emacs can be that tool for vim users.
In order of precedence: Standard vim movement -> EasyMotion -> Search.
I have my own code editor which is more like vi than emacs, but I'm using interactive search in it.
That's the best line I've heard to finish an emacs-vs-vi argument!
On the other hand, C-a and C-k (especially in combination with each other) and C-e are incredibly useful, and once I discovered them I immediately started using them everywhere.
Though I also tend to use M-f and M-b a lot to navigate by words instead of characters.
I also often navigate by incremental search.
Why? Isn't that more inefficient because you have to move your hand off to the side. I can type 3 C-n before moving my to the right to do a single down arrow. Maybe I am just used to it by now, and forgot how hard it was when I started, but it makes complete sense to me.
Yes it's hard to get started, but once you get the hang of it navigation in emacs just becomes so painless.
Also it's hard or even impossible at first to do it on laptops but trust me you will be able to do it.
that's the old-school Starcraft way. try mapping caps-lock to control sometime, just to see, it's such wasted real-estate. nothing beats muscle memory and years of practice though.
Then you add slimv to the mix. Honestly I never gave slime a fair shake. I barely scratched the surface. But once I got slimv up and running, I felt like I didn't need to learn emacs+slime. Maybe there are some things I don't know about that I'm missing out on, but slimv, like vim, let's me think in lisp.
So if you're a lisper and you like vim, don't jump ship yet! Give slimv a shot.
What do you use it for? It seems if you're using common lisp it's perfect, for everything else it works "in principle" but not really.
To be honest I found it more straightforward to use, and the great thing is that it doesn't require any Swank servers to run, and it works with just about any REPL based language. I find it hard to live without it nowadays, though if you're on windows I would expect you'll have difficulties in using this.
And yes, CtrlP is probably the thing you'll miss most.
But all the other things I got from switching from Vim to Emacs+Evil easily outweigh the missing CtrlP.
Vim was great, until I wanted to customize it heavily. It is simply not made to facilitate things like: child processes, SSH, understanding my code, a visual interface for Git.
Emacs comes stock with good tags support; once you've built a tagfile, M-. on a tag will take you to its definition. (I don't use tags myself, although I really should, so I don't know whether Emacs can automate construction and update of a tagfile, but I strongly suspect it can; check the relevant documentation for details.)
It also does a great job managing child processes and SSHing. (Or FTPing, or speaking whatever other protocol you need to use to access remote files.) I can't speak to it as a visual Git interface, but I don't doubt it's at least reasonably good at that, too.
"Do one thing well" is a good start, sure. But why not aspire to more?
And Emacs has a command line for its stuff: "M-x".
And if you really want to have separate executables you can do that with small 'emacs --eval' wrappers.
Emacs provides a lisp implementation. People have used this lisp implementation to write ftp clients, web browsers, and yes even text editing functionality; you then use emacs to load some of that lisp code and execute it. I don't say the Bourne shell fails at "doing one thing well" since people write shell scripts and run them from within the shell.
mkdir ~/tmp/foo
scp -r user@host-a:/foo/bar/* ~/tmp/foo
scp -r ~/tmp/foo/* user@host-b:/foo/bar
rm -rf ~/tmp/foo
ssh user@host-a 'cd /foo/bar; tar -cf - .' | ssh user@host-b 'cd /foo/bar; tar -xvf -'
cp -r /user@host-a:/foo/bar/* /user@host-b/foo/bar
ssh user@host-b
ls -R /foo/bar
ls -R /user@host-b/foo/bar
Oh, and lest I forget, if I want to edit a remote file in Vim, I have to either ssh to that host and invoke vim there, or scp the file here and invoke local vim on it, or deal with sshfs or something -- the latter of which might seem like a perfect solution, until you consider that I use all of Linux, OS X, and Windows machines extensively in my daily life, and not all of them do sshfs well or at all. By comparison, eshell's
find-file /user@host/foo/bar/file
There's value in having lots of loosely coupled tools, but it's not the only paradigm worth considering. There's also value in a single, unified interface to an enormous range of tightly integrated functionality; indeed, I've found the result to be something of a combinatorial explosion of productivity.
Do you really demand that an OS should only 'do one thing well'? :ø)
sudo aptitude purge emacs
sudo apt-get install vim gvim
gvim
If you stop and think about it, it's really pretty much impossible to define the "one thing" a code editor does.
Forcing the user build everything out of shell pipelines is not the goal, and achieves nothing. At some point, it is appropriate to build the aggregate and combine these functionalities for the user so that he doesn't have to do it himself. And in many cases, you end up reimplementing the thing because it is more efficient that way. The shell utility is still there for the user should he need it.
For example, be an outstanding VM, IDE and a thriving ecosystem of libraries for development in a quite nice (and becoming better with each version) Lisp dialect.
Anyway, that's really a matter of preference. It's ok if you want to tell the world about yours, but try to word it in a way which isn't confrontational for people who have different preferences.
Emacs, as has been said time and again, is not a text editor. It is, if anything, a development shell. It contains a text editing program (the default program), and that program does not manage child processes or SSH or Git.
You could also take the stance that Emacs _is_ a program that "does one thing well:" develop programs. That's the actual task of importance. Text editing is a secondary, ancillary task that owes its importance entirely to the archaic practice of representing complex interrelationships between data and operations on those data as a static linear stream of ASCII-encoded bytes.
Unfortunately, almost all programming languages are like this (hence, "languages"), but if you ever use Emacs to edit Lisp, you'll find that it's far less like text editing than it is like directly manipulating the abstract structure of the program. It does a reasonable job trying to replicate this experience in other languages, but when you have utterly inane constructions like seventeen-precedence-level infix notation, there's only so much you can do.
or like Vim! (as in Evil)
Use ed to edit, and pick a side in the more/less wars if you want to read it.
I'm not a vim user, but I use it to replace less because syntax highlighting is the bee's knees: (you may need to change `vim74` to whatever it is on your system.)
alias less='/usr/share/vim/vim74/macros/less.sh'
less Makefile +400
pygmentize foo.py | less -rI'll probably be sticking with boring old Vim and the command line.
Both Vim and Emacs have a horrible time trying to syntax highlight Perl, but I find Vim's flaws to be more tolerable. Emacs isn't some sort of panacea.
(defalias 'perl-mode 'cperl-mode) ; perl-mode sucks; use cperl-mode " @{[ blah() ]} "
In Vim:
my $variable = <<EOF;
STUFF GOES HERE
EOF
my $variable = function_call(<<EOF, $blah);
EOF
[edit: I tried to replicated this, and I'm not seeing the HEREDOC portion highlighted as a string, but I also notice that Perl 5.20 has removed <<HEREDOC in favour of <<"HEREDOC" or <<'HEREDOC', so maybe that made parsing for syntax-highlighting easier.]
Also in Vim:
"text @{[ callFunction(sub { }) ]} text"
It's documented in the code - more or less - and I'm very happy with it, especially with having multiple directory sets I can change between (which I implemented recently) and how fast it is (aside from initial caching done by the ruby backend).
I actually never thought about releasing it publicly, so the readme is non-existent and the Ruby script is hacked with hardcoded ignores, fonts are not customizable, and it's even possible that I hacked the Ruby gem source at one point. I could clean it up a bit if there was some interest in it.
Actually, Vim is the next Vim--it only seems to get better and better.
After switching to Vim full-time about two years ago, I recently tackled exporting the text from a 10-year old PDF to markup it up using AsciiDoc[1] so I can output HTML and ePub.
It’s over 37,000 words but I was amazed how easily I was able to jump anywhere on the screen with just a few keystrokes fix all of the little things that need to be fixed in a text file.
And because editing paragraphs of text is somewhat different than what I normally do (writing HTML and CSS), it was pretty cool being able to leverage the composability[2] of Vim and how seamlessly that knowledge works in new contexts.
[1]: http://www.methods.co.nz/asciidoc/index.html [2]: https://medium.com/@mkozlows/why-atom-cant-replace-vim-43385...
I use tmux, so all the advanced functionality of the terminal is only a single keypress away (to switch to another open terminal split).
Perhaps grandparent wants something like that in Vim if it does not exist already.
Watching a seasoned vim or emacs user create, mold, shape, reformat text like it was a piece of clay in the hands of a potter is truly inspiring.
As for me, my instrument of choice is Sublime Text (which, I guess, downgrades me to the status of a flute player), though I occasionally use vim for Ops stuff. I think there are some mac-centric UX patterns that I have a hard time giving up.
I can certainly understand that; I'm a relative newcomer to the platform, and while Emacs (of course) continues to behave regarding meta keys in the fashion I've spent a lifetime learning, getting used to Option-arrows for "move to next/previous word", and Command instead of Control for shortcuts, is really bothering me.
(Of course, that's mostly just because forcing the user to cramp her hand up like that, in order to access even the most commonly used keyboard shortcuts, is just a really stupid and un-Apple-like piece of user interaction design, and I've yet to find a good way to fix it.)
Maybe I'm misunderstanding you, but it sounds like you're using one of the Mac OSX ports of emacs that tries to make emacs behave more like a Mac app. My advice is don't do that. Use emacsformacos.com [1]. It's plain ol' GNU emacs built for the Mac platform. I was so glad to find this and quickly gave up Aquamacs. I want my emacs to behave the same whether I'm on Mac or Linux (or Windows for that matter, but I'm doing less and less on Windows these days).
Let me know if I've misunderstood you!
[1] -- http://emacsformacosx.com/
To expand on that point: what I'm complaining about is the fact that OS X, and native apps, use the Command key, which is where Alt would be on a PC keyboard, as the meta key for shortcuts which on a Windows or Linux box are bound to Control. This is a terrible idea from a UX perspective in general, because every common keybinding requires a hand cramp to invoke. From the special perspective of someone who remaps Caps Lock to Control, it's even worse.
I'm probably going to end up remapping Caps Lock to Command instead, and reconfiguring Emacs and iTerm accordingly; it looks like that'll work out to be a pretty complete solution to the problem. (I hadn't previously thought to check whether iTerm supports meta remapping, but it does, so I can have my Command key behave as Control when I use it in terminal applications.)
(Unfortunately option is still needed for certain symbol, like /|\, in many keymaps, but that's the mac's fault , not emacs.)
https://pqrs.org/osx/karabiner/
I use it to map the emacs navigation keys for use across the OS, and find it really improves my experience. If you're interested in that set up, I use the following options, which are all listed under Emacs Mode: - Control + PNBF to Up/Down/Left/Right - Control + A/E to Command + Left/Right - Option + B/F to Option + Left/Right - Control + D to Forward Delete
Of course, I have caps lock remapped to Control.
There are also Vi remap options in Karabiner, plus tons of other stuff.
Disclaimer: I'm a bit of an emacs lightweight, so it might be that the remapping options aren't as full-featured as what a more advanced user would like.
It's like moving to a foreign country and then continue to buy and to eat only your old local food, and go out and talk to only people from your old home. You will miss so much.
After 20 years of switching back and forth I decided I wanted an extensible editor not a programming language with an editor built in. That's worked well for me.
I really always just want the simplest thing that will work as I need to rely on it entirely and understand how it works. If I was to use emacs, I'd probably use mg as shipped with OpenBSD.
Why? Emacs reports errors fine in my experience and if not it includes a debugger.
> or you have to delve into elisp
What's the problem with elisp? I guess its a matter of preference, but in my opinion elisp is easier to understand than vim script. Emacs includes extensive(!) documentation for it in it's base distribution. Granted, it's a dated language nowadays, but 3rd party libraries - easily installed through elpa - like dash.el and s.el make it a much more pleasant experience.
> or you get carpal tunnel...
Again: Why? This article is about viper-mode which emulates vims key bindings so RSI should be exactly as likely as with vim itself. You could also adapt them to your needs, of course.
I don't really want masses of extensibility but what I want is something that works out of the box, is understandable and doesn't require masses of customisation that I have to drag around with me everywhere.
On this basis using viper with Emacs is as illogical as using vsvim with visual studio. One should use vim (or vi which I'm equally happy with)
Things like vsvim or emacs for eclipse become incredibly useful when you want to keep your productive habits in these clunky IDEs.
So I was trying to make Emacs not drop its stupid temp files next to the opened file and found this piece of incomprehensible code:
(setq backup-directory-alist
`((".*" . ,temporary-file-directory)))
set backupdir=~/.vim/backups
I still haven't gotten it to work.
Meanwhile in Vim
set numberThis is actually quite nice to customize because you can change little bits of behaviour by just adding another pair (regex . string) to the list. Typing "C-h v backup-directory-alist" also explains what the list is for and lets you customize it with a gui.
I think the second part kind of misses the point, as someone in vim has already implemented the feature you wanted, the way that you wanted. So you are basically turning on a parameter.
What is much more important to ask here is how would I implement that functionality [in whichever editor] from scratch, and can I even do that?
Turn on line numbers everywhere by putting this in ~/.emacs.d/init.el:
(global-linum-mode)
linum-mode
M-x customize-group RET linum
They also can run in a remote console which for me is reason alone not to use another editor.
As a developer, that makes no sense to me. Do you really need a powerful remote editor? What do you need a remote editor for, other than checking that a config file was set up correctly, or reading a log file?
And a virtual machine seems portable, but I cannot use it on my phone/tablet, and I also cannot use it on most other machines that don't have that virtualization software installed.
Also, quick & dirty code changes on development/QA environments when it needs to be fixed ASAP.
There's not many uses as you mentionned, but there are times when its really useful.
Another perk of it is using tmux and having a consistent environment you can tap into from work, home, the road, etc.
I have nothing in my work machine but a linux shell. I just vi everyplace in the world, edit things there and compile there and then scp to the product. My work is 100% remote.
Years ago, I finally made a little time-investment in learning Screen, and it has definitely paid off. I hear that tmux is better, but I don't have any missing requirements from my current setup, so I haven't tried to learn it.
That makes vim/emacs not only fast editors in the processing sense, but editors where you can be really fast at what you do. All this comes at a steep learning curve, which is the only downside I can see.
The Vim plugin for Visual Studio is very good, in my memory. Note that Kate has also a pretty good Vim mode. There is also a decent free Vim plugin for Eclipse [1].
My thought is: "Let's change the next 2 words", my fingers type c2w (change word).
The bindings take quite a while to learn, I started using vi mode in komodo edit, but once I realized that bindings like ci" didn't work I switched over to macvim. I haven't used any other editor since then (4 years ago).
The other reason is that I mainly "develop" (hobby) on my vps, having a vim session open in tmux allows me to use nearly any pc in the world and I'm in business to continue where I left off.
My brain does not work like vim at all. I do not count words. I do not think about whether I want to change, jump or delete. Therefore, I've never been able to use any vi flavor even semi competently: I can technically work in it, and I have read about all the commands, but I am actually slower in Vim than I'd be in windows Notepad, because it's internals do not 'speak' to me at all.
I had a lot more luck with emacs, because I can ignore anything that even considers those low level operations, and just use it's higher level features, like buffers.
Still, I end up doing better in an IDE, because most of my editing is of code, and an IDE understands the code I am writing far better than emacs or vi could.
I've used Vim for a few years. I enjoy editing in it for sure. But it does feel like it optimizes the wrong thing. By the time it's time to write code, I'm more invested in the ideas than the mechanical action of implementing them. I also feel like core Vim is very good, but the experience suffers greatly once you enter Weird Plugin Land, where you need to set SpecialOption if using RandomPlugin version 0.88. I get why it happens; it's also a waste of time.
I don't have the patience for that. I dread maintaining my vimconfig for this reason.
Yes, learning the basics is harder than with other editors. Once you master them you have a superior tool you'll be able to use for the rest of your life.
Vim is just part of that tool chain designed to edit text efficiently. Vim is not so much a text editor as it is a language for manipulating text. Vim has dozens of motion commands to move cursor over chars, words, sentences, paragraphs, code blocks, methods, pages, regex etc. So general form of vim commands is nCm i.e. repeat n times command C to the text cursor moves over with motion command m. So for example w is a command that moves to the next word. d is a delete command. So, dw says delete word. 5dw says delete next 5 words. Let's say you are inside if (.) block and you want to change the if condition. ci( says "change inner bracket text" (i.e. everything inside brackets). This deletes everything inside () and puts you to INSERT mode and let's you type new condition.
This makes Vim extremely predictable and discoverable. You learn a new command say gU (turn to upper case) and you immediately know how to turn to upper case entire word because you know how to move by words with w. gUw turn entire word to upper case. gU) turns entire sentence to upper case, etc.
After a while these things just become part of you, and you become really fast at bending text to your will without even thinking. The fact that you can navigate text/code and get to where you want in matter of milliseconds (faster than it takes you to take the hand off the keyboard and reach for the mouse, shake the mouse to find where the cursor is etc) is amazingly liberating of disruptive context switches.
And then if you add shell integration, it means you can apply advanced filters to your text to do pretty much anything. This gets as esoteric as run filter on regex in lines that match another regex, where regex can be any Perl compatible regular expression. But can also be as simple as reformat code, beautify paragraph, insert current date, listing of directory etc. Then you add code completion, file navigation etc and you have something amazing.
Only if you never experimented with a Lisp / Smalltalk REPL from the old Xerox PARC environments.
EDIT: Should have mentioned the later Lisp Machines and Oberon (specially System 3) as well.
ftp://ftp.vim.org/pub/vim/doc/book/vimbook-OPL.pdf
Also read entire exhaustive help at least once so you get the idea of what is available (it can be done in one weekend, don't try to memorize too much just familiarize yourself with content, then later when you wonder how would you do that in Vim you will remember you read something about that once).
Vim has really great indexed help that you can access directly:
:h :h index :h <topic>
and there is also grep for help to search entire help for matches
:helpgrep <search_term>
No matter what you do understand that you will get slower before you get faster. At first expect your productivity to go down seriously, because everything will be strange and new. But persist with it and force yourself to use it. Once you get to the nicer bits you probably will not want to go back. After 6 months of regular use, you will not be able to back, every other editor will feel dumb and will frustrate you to no end (be careful when typing email: ESC key dismisses the compose dialog in a lot of email programs without asking you anything :D).
As for UNIX shell and tools, again get a good BASH tutorial book and learn the basics of interactive shell, learn how to do loops, globs etc. The rest is then all about learning individual tools, not shell itself, which is rather small command interpreter. Look in your /usr/bin and /usr/local/bin for commands and read their man pages. Experiment a lot with them and look at examples of creative use of these.
Back in the early 90s I had a year long course in vi (not Vim) but started using Vim on Amiga 500 days, and after 20 years I still come across new commands and ways to do things. This is the beauty of Vim, you grow with it and it never stops to amaze you. But it is a skill that you keep for a lifetime. It's like learning to touch type, you do it once and you type efficiently for the rest of your life. You may get faster or slower at times in your life but you are always faster than hunt and peckers. Same with Vim, dumb editors come and go, but none ever approach the completeness of Vim.
Vim and Emacs have survived because they are "fit for a purpose"... they are really good at editing text! Emacs has a niche in expandability. You can always twist Emacs to do your bidding... and it has a culture of tinkers. Vim has much more of a culture of users, people who want to edit text rather that toy with their editor.
These editors have roots in the 70s and are still kicking -- that isn't some random accident, that is because the fundamental act of editing text hasn't change too much.
I don’t know about that. I really got into Vim because it’s so customizable. The number of general purpose and very specific plugins is pretty amazing.
And the Vim Awesome site that tracks plugins is pretty damn awesome: http://vimawesome.com
Emacs is more -- of its own things -- lots of people write little bits of elisp to do their bidding, and the "plugins" can completely reshape the editor into an IRC client... a mail client... a media player ... a connection to spotify ... etc. It is a wild crazy world powered by elisp.
I'm often curious how productive it would be to use while coding.
1: https://en.wikipedia.org/wiki/Canon_Cat Bonus link: http://clickamericana.com/media/advertisements/the-canon-cat...
However, if you're just editing text on the same screen you can skip the search. I have it set up so that I press ,w and then every word after my cursor has its first one or two characters replaced. I can jump to any word by pressing those. There's also a hybrid mode where pressing one key and then the first letter of the desired word highlights only those matching words on the entire screen, which I can then jump to.
So, to answer your question about what it's like: it's great!
This alone was enough to move me back to Vim. Everything else about Emacs was awesome. I would love to go back if I could get over this one problem..
(setq evil-esc-delay 0)
I completely do not understand how switching modes is a good idea in an editor. It just doesn't fit in my brain somehow. I start typing and randomly end up pasting and cutting. I want to paste and cut it randomly types my commands in insert mode.
Emacs cords are pretty intuitive to me. I don't know many: just moving, saving, creating 2 windows, search & replace, cutting and pasting. There are hundreds more, but you can get away with a few basic ones.
Save needing to rebind the Ctrl key to CapsLock, emacs key-bindings are optimized to not have to move the hands to the mouse or arrow keys, which I appreciate. Vim's are as well, but again I don't like modes, so there is that.
I tried emacs until my pinky hurt so bad I switched to vim.
So no, emacs is not modal like Vim. But good try, good try...
Besides, why not use speedbar, that opens a nice directory browser and you can open files by clicking on them.
Do you ever use keyboard shortcuts... Ctrl-A, Ctrl-F, Ctrl-C, Ctrl-V, Ctrl-Z, Shift-End, etc.? Extrapolate that to everything you might want to do when reading, reviewing, or editing a text file.
The vim command structure makes it trivial to define transformations on common blocks of text; words, sentences, paragraphs (lines), blocks of code inside {..}, etc. It makes it easy to repeat those commands, by repeating them a fixed number of times, applying them to every instance in the file, or asking for confirmation around each one.
But, most importantly, it means that we can now extract that little bit of text-transforming functionality into a script we can save and bind to a new command (if it's something particularly reusable). This is really what vim is about to me - providing a language to describe text transformations, in the form of sequences of commands. This means that the way I code every day, conveniently saving me a few seconds like you mentioned above, is the same method I use when writing/editing plugins/macros for the editor to do more complicated tasks, like say consistently formatting every line of a log file that begins with [ERROR] and removing all other lines, so we can process it with some other tool.
Sure, you could write a script in [python/perl/ruby/etcetcetc] to do all that just as well, but the point is that Vim provides a nice little domain specific language right at your fingertips, optimized for working with text at a higher level, capable of handling one-off jobs as easily as big jobs over a whole log file or even as a little command to be reused later.
It's not always about pure efficiency metrics. I code better when I enjoy using my tools.
Then, if you worry about fuzzy project finders, better one exists that does not need fuzzy (I ditched all fuzzy finders for it): http://tuhdo.github.io/helm-intro.html
Learning Emacs or Vim is an investment, one that last your entire life. I will gladly be less productive for a few weeks to gain much more in the long run.
But for CSS/SCSS and JS I find easier to use espresso[1]. That's because it's made for web-dev and I don't need to setup my own workflow. I believe same thing is with Sublime Text. It's better to use for web-dev IMHO compared to VIM/EMACS.
ps. That said, I always believed that the editor is a tool. It's better to learn your current editor's ins and outs than switching back and forth from editor to editor.
I was fed up with having to switch to a newfangled editor every so many years, having to identify new plugins, having to learn new keybindings. I've used Vim for 7 years (I think) and it came pretty close, but in the end the archaic VimScript language and the lack of async commands was something that was nagging me. I wanted to call an editor home, and hone my skills until I pass away, increasing my arcane knowledge over 10-20 years, learning ever more about the scripting language, commands, and writing more and more specific plugins that help with my tasks.
I still want to be coding in 10 years, but I don't want to switch text editors ever again. Emacs shall be my final editor [1], and that's why I decided to switch. Because I can see Emacs still going strong in another 20 years. I wouldn't want to say that about Sublime, or really any other editor right now.
[1] There's a case to be made that NeoVim is going to be great, and it may well be, but right now I'm really, really, really happy with Emacs + Evil. Nothing is perfect, of course, but the things that bug me are really, really small things that I could probably even fix, if I'd invest enough time; but they don't bug me enough for that.
I guess the real problem is me saving too often. Others may be trying to run a long make from vim and wanting to continue editing or looking through files.
I can't say that you should switch, or that it's superior to anything, but I think you could at least give it a try. And by this I mean: use it as your only text editor for as long as you can invest (a week, maybe a month). Start with the built-in tutorial, install: ido, web-mode, js2-mode, maybe add yas-mode. Install a nice color theme. Learn the key bindings in web-mode to efficiently navigate HTML documents. Try to perform some tasks using macros. While editing try to forget you even have a mouse. Discover the little things, like "undo" being able to be narrowed to the selected lines instead of global linear history, or the kill-ring (you can paste form previous "cut" operations, not just the recent one).
There's some un-learning and re-learning of everyday tings like the shortcuts for copy/paste or the concept of selection vs. region, but for me it was a good investment. I can't say it'll be good for you, but I encourage you to try - if you won't switch you'll at least get a better understanding of what you like about your current editors.
There is currently nothing in Emacs (last I played with this was 3 months ago) that is 100% equivalent to CtrlP. There are some close approximations but they're not as good the real deal. I can understand how Emacs guys won't even notice this because they've not worked with something that's better than the best they have, but for Vim guys it sucks.
Have you tried projectile? From reading the Readme this was exactly what I was looking for as a Ctrl-P replacement.
Demo: I can search my desired file in linux kernel source with more than 40k files in an instant: http://tuhdo.github.io/helm-intro.html#sec-28
If you want to find the equivalent, use ido + flx + vertical-ido.
You can have it all, emacs, and vi... so, what is the bigg fuss?
A lot of developers forget that there exist other methods of input, and mnemonic-based shortcuts are one of those things that make a lot more sense than attempting to optimise for a tiny reduction in finger-movement (which ought to be the domain of the input-device anyway).
I actually use viperre with a Colemak keyboard map, but there's a QWERTY mode too.
https://github.com/bbatsov/prelude/blob/master/modules/prelu...
The latest nightlies and pretest (the ones marked "Multi") have this fixed. It's a super frustrating bug.
You can enable the prelude-evil.el module and start out with a nice set of bindings. It would be sweet if there were some more pull requests to make the evil-mode bindings in prelude more closely match vim.
C:\cygwin64\bin\run.exe /usr/bin/bash.exe -l -c emacs-w32.exehttp://www.emacswiki.org/emacs/PythonProgrammingInEmacs
Couln't get flymake and pyflakes to work. pymacs was a non-starter so I couln't use ropemacs.
I also tried CEDET, but that was an epic fail.
BURN THE APOSTATE!
[Will this do?]
... do a little more thinking and never have this problem again, learn to adapt to whatever text editor is on the system etc.
But I still don't think "you might have to use a machine that only has vim installed and not your preferred editor!" is a good reason to spend time mastering how to use it (which is what I often hear). If you prefer emacs or sublime or whatever, use it, and just put up with vim if you're on this hypothetical scenario where they're not available.
I find that in actual operation Emacs is faster and that's the reason I switched from Vim to Emacs. Even after using all the tricks in Vim's :help tex-slow, Vim still lagged when I scrolled or even typed into LaTeX files (unless I turned off syntax highlighting), and I'm not such a great typist. Emacs is perfectly snappy.
But yes, I admit that I find silly that I should need a 'server' for a text editor. Not to mention that I remote into various VMs regularly which would also need to get their own server/client setup if I wanted a homogeneous working environment.
I use emacs in a work environment that is primarily Vim and where we end up logging in to a lot of machines to do development on, and the two things that turn heads in my emacs setups are my fluent and flexible use of multiple windows and frames, and the fact that I'm always using my local emacs and I use Tramp to remote in to the machines, so I don't have to screw around with .vimrc files on half-a-dozen machines. Both are stock emacs.
But moving to Emacs had many other benefits, so I'm definitely glad I did it. The LaTeX is just what made me look for other editors, being the one thing that really bothered me about Vim.
And about the remote VMs: as user jerf said, you only run one Emacs, on a local machine, and use Tramp [1] to edit remote files as if they were local. It's great!
(package-install solarized-theme)
(load-theme 'solarized-dark t)