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
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.
I have my own code editor which is more like vi than emacs, but I'm using interactive search in it.
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.
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.
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.
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...
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.
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.
Use ed to edit, and pick a side in the more/less wars if you want to read it.
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?
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.
Do you really demand that an OS should only 'do one thing well'? :ø)
I'll probably be sticking with boring old Vim and the command line.
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.
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.
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.)
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.
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/
(Unfortunately option is still needed for certain symbol, like /|\, in many keymaps, but that's the mac's fault , not emacs.)
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.
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 numberI 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)
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.
They also can run in a remote console which for me is reason alone not to use another editor.
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.
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?
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
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.
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.
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].
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
Have you tried projectile? From reading the Readme this was exactly what I was looking for as a Ctrl-P replacement.
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.
(package-install solarized-theme)
(load-theme 'solarized-dark t)