Maybe I am just not getting it and this is a sincere query for the emacs people out there to show me the way. (Vim guy that wouldn't mind switching but hasn't seen a compelling case for it other than the fact that emacs lisp is the bees knees.)
Maybe I am just not getting it and this is a sincere query for the emacs people out there to show me the way. (Vim guy that wouldn't mind switching but hasn't seen a compelling case for it other than the fact that emacs lisp is the bees knees.)
After 3 or so years of using Vim heavily I started hit the limit of what can be done with defaults, simple options adjustions and even plugins. I honestly tried to use Vimscript, but I couldn't bring myself to do this for real. I knew some Scheme then, so I wasn't afraid of Lisps. I switched and I immediately started implementing things I wished I had implemented months earlier in Vim. My Vim config was ~700 loc and it had only a few custom commands defined in it after 3 years. As I mentioned in another comment my emacs config is ~4k loc now and defines a multitude of advices, hooks and plain commands after half a year. It grows almost every day and what's most important is that coding to Emacs APIs in ELisp gives me much more pleasure than coding in Vimscript.
Lastly, modality - somehow I'm not missing it. It's not that I've seen the light and now think that modal editors are an abomination, but I came to appreciate modeless-by-default model of editing. Emacs ofers many ways to enter modal mode, so when I felt that modal interface would be better for something I just coded it so it's modal.
In short - if you're a happy Vim user who doesn't feel the need to write your own Vimscript (or you're happy with Vimscript!) then I see no reason to switch (maybe org-mode or something, but that's a very specific case). But if you thought at some point that you'd like to code up something in your editor but didn't because it was too much of a PITA then give Emacs a try.
Is your config out there in the wild?
I did. It's nice - it actually emulates Vim instead of Vi, which makes a huge difference. With proper plugins you get even things like surround and increment/decrement number at point. I stopped using it temporarily because it didn't work well on my Windows machine and when I moved to *nix-only Emacs I forgot to enable it back. It's great for reducing the shock of switching though :)
> Is your config out there in the wild?
It somewhat is, although it's not the greatest thing in terms of organization or portability. I'm telling myself that I will move to el-get and stop having all the plugins in this repository and so on, but I didn't do this yet. My own code is here: https://github.com/piotrklibert/dotemacs_reloaded/tree/maste...
Just to set the record, I use evil-mode on Windows and haven't had any problems. I also use it on Mac/Linux and haven't noticed inconsistencies.
But didn't I hear something about Python being usable as a Vim extension language? I'm not terribly fond of Python for aesthetic reasons, but it's at least as powerful as any of the modern scripting languages, and it has features (like docstrings and list comprehensions) which I'd really like to see more widely adopted. Have I misunderstood the state of things? Can a Vim user not actually say "F this Vimscript nonsense, I'm switchin' to Python!" and get as much power over the editor as Vimscript would've offered?
That said, it's possible that a large percentage of people use a Vim binary with Python/Ruby/etc. support. I have no idea what the usage statistics are.
On the one hand, if you install a "starter kit" like Prelude and it works properly, then it might give you a little boost up the initial slope of the learning curve, but it's going to slow you down later on because you're learning how Emacs + Prelude does things rather than how Emacs does things. This becomes problematic when you try to interact with Emacs users unfamiliar with Prelude, because they don't have any knowledge of the changes Prelude makes to the environment, some of which result in incompatibilities between Emacs + Prelude and just plain Emacs. (I've run into this when answering Stack Overflow questions, to the extent that if I see a question where the asker mentions using Prelude, and it's not immediately obvious that the problem at hand could not possibly be related to Prelude's changes, I just pass on by.)
On the other hand, if you install a "starter kit" like Prelude and it doesn't work properly, then you're pretty much boned, because you have no knowledge of what the misbehavior you're seeing signifies, or how to hunt it down and fix it. Not only does your editor not work right (or at all), but, because you've installed something which advertises itself as solving a newbie's every problem, you're not mentally prepared to deal with something going wrong. Worse, you've just had your initial experience with Emacs spoiled by brokenness; worse still, you aren't likely to know enough about Emacs to recognize that it's Prelude to blame, so you end up with a poor opinion of Emacs that really isn't its own fault.
Just start learning Emacs. If you can figure out how to write code in the first place, learning Emacs is not all that hard, and before very long you'll wonder why you ever thought you'd need training wheels.
I'll refrain from making the obvious Star Trek reference, and instead use this meta-reference.
This is especially true in the case of a Vim user, because, unlike most editors (Sublime Text especially), Vim is roughly comparable with Emacs in terms of raw editing power. Each is about as powerful as the other, in most respects, and each has borrowed concepts from the other over time -- some Emacs modes are "modeful" in the Vim sense, in that you might, for example, press 'e' to enable editing in an Occur (regexp search across file) results buffer, and C-c C-c (control-C twice) to switch back to browsing mode; in the other direction, I hear Vim has windows now, as well as buffers.
The difference between Emacs and Vim isn't so much one of basic capability as of perspective on the world; Vim is (more or less) the quintessential Unix editor, very lightweight and deriving most of its power from the broad range of tools provided by the platform. Emacs, on the other hand, is more or less a virtual Lisp machine with a text editor built on top of it, and while many of its capabilities work in concert with external programs, it is as much as possible designed to behave independently of whatever platform it happens to be running on. The cavil that "Emacs is a great operating system which just needs a good text editor" is, as with many cavils, not entirely devoid of truth; rms has I think never stopped grieving for the MIT AI Lab and its Lisp machines, and a lot of the early design decisions that went into GNU Emacs were driven, I think, by a desire that it should offer at least a broadly similar environment -- turning a Unix box into a Lisp machine in spite of itself, if you will. (After a few years using Emacs, I can understand what makes that a desirable result, too.)
But, overall, either editor can do anything the other can, to the extent that the editor war has no clear winner; if you use the tools you're comfortable with, and get as good at using them as you can, then it's hard to go too far wrong.
On the other hand: Emacs has Tramp, which is far and away the best tool available for transparent remote editing. If you can get to a file by any means more immediate than emailing it back and forth, you can open it in Emacs, edit it, and write it back, with only as much additional effort as is required to identify the host and authenticate for whatever protocol exposes the file. And, unlike FUSE, it works identically on every platform where Emacs itself compiles, which matters to me because I use all of Linux, OS X, and Windows, for both work and play.
Better still, Tramp ties into Emacs' built-in shell, so that you can, for example, 'cd /host:/path/to/some/directory' and run shell commands there, copy files back and forth between local and remote directories or from one remote host to another, so forth and so on, and have everything behave exactly as you'd expect. For someone like me, who spent years sshing hither and yon, opening another xterm to scp something across without having to drop a remote shell, et cetera and so forth, Tramp, and especially Tramp + Eshell, amounts to a revelation. I'd never used anything like it; I'd never imagined anything close.
If what you're using right now satisfies your needs, then I wouldn't recommend Tramp and Eshell as a reason to switch. But if your needs change, to a point where what you're using right now can't live up to them, it's an option worth keeping in mind.
GNU Emacs is an editor written and extended in a dumbed down dialect of Lisp, on top of a dumbed down Lisp runtime, on top of some kind of other operating system. It provides a relatively poor user interface (especially compared to the real Lisp Machines which existed).