[weaksauce]

I like the idea of emacs... Every time I read a list of plugins like this I get put off by it though. I want an editor that does editing well and helps me edit source code faster. These lists, for the most part, show how emacs has git integration that's better than the command line(not too hard a task), or rvm switching(how often is this really needed? Set it once in the .ruby-version file and be done with it), or some other external program that can be brought into emacs and have marginal utility.

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.)

[klibertp]

Well, I switched to Emacs from Vim exactly because of ELisp. Or rather because of Vimscript: I thought that Lisp or whatever, even Forth would be better than Vimscript :)

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.

[weaksauce]

Have you tried the evil mode or whatever vim emulator suits your fancy?

Is your config out there in the wild?

[klibertp]

> Have you tried the evil mode

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...

[justinmk]

> I stopped using it temporarily because it didn't work well on my Windows machine

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.

[aaronem]

Well. I'd never taken a close look at Vimscript before. Ye gods.

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?

[actsasbuffoon]

Ruby is also usable, as are a few other languages. Unfortunately you need to compile Vim with support for a given language if I recall correctly. VimScript is the only extension language available to all versions of Vim, so that's a consideration if you intend to share your creations.

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.

[aaronem]

The impression I had was that Python had become a de facto standard Vim extension language, but evidently that's very much not the case. Definitely a drawback; it's nice in the short term, perhaps, to be able to choose your favorite among various scripting languages, and use that to extend your editor, but in the long term it seems likely to result in a lot of fragmentation.

[lucisferre]

I'm curious if there is an efficient way to transition from VIm to Emacs. I've wanted to for a while now but dread the lost productivity from making the transition.

[mdellabitta]

Don't install any plugins. Emacs is definitely usable out of the box. One of the attractions to it is that it's a meta-editor environment that you can use to build any editor you want, but you don't have to. Only bother installing a plugin if you have an itch to scratch, and you'll be fine.

[aaronem]

Strongly seconded.

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.

[klibertp]

Not to mention Tetris is in the default installation anyway ;)

[qbrass]

The concept seems to be that once you've adapted to Emacs, doing things outside of it becomes a pain point. So you start bringing everything into Emacs.

I'll refrain from making the obvious Star Trek reference, and instead use this meta-reference.

[aaronem]

I'm never greatly impressed to see a fellow Emacs user saying "Here's the libraries I use, ain't they great? You should switch!" The effect is almost always what it's been in your case: someone looks at the list, says "My God, it takes that much to make Emacs usable?", and resolves afresh never to touch Emacs with a ten-foot pole.

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.

[lispm]

A Lisp Machine is a real computer which runs Lisp on the metal. One of the applications of a Lisp Machine is one or more editors written in Lisp.

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).

[aaronem]

I never had the privilege of using a real Lisp Machine, so the difference isn't obvious to me. Thanks for the correction.