"I had to spend around two full years memorizing key chords"
Yet another user who thinks emacs is about the key cords. It's not, it's about extensibility. I changed most of the default key bindings, because they were inconvenient.
Remember: Emacs should adapt to you, not the other way around. That's what Emacs is about.
Yes, yes, yes! I came here to write exactly this: what is the point of having infinitely configurable and extensible editor if you don't configure it and extend it to your liking?
The very first thing I did after switching to Emacs was to rebind most frequently used keys to something sane. The next thing was to make the functions themselves sane - IIRC the first command I wrote was "comment-or-uncomment-region-or-line".
My emacs config is about 4k lines of my own code at this point, very little of which implements anything by itself. It's full of customize-options, hooks and defadvices, eval-when-loads and similar things, which make Emacs into my editor. If I had to learn some defaults I couldn't change I would just use some IDE or another editor.
> the first command I wrote was "comment-or-uncomment-region-or-line"
verilog-mode (and I imagine others) includes something like this this. C-c C-c comments region, and C-c C-u uncomments it. It handles embedded /* */-style embedded comments intelligently.
I don't want to hit different keys for commenting and uncommenting! What I want is to have one key which does all this:
1. if there is no region active and current line is not commented - comment it
2. if there is no region active and current line is commented - uncomment it
3. if there is region active and it's fully commented - uncomment that region
4 otherwise comment the full region
And it's this easy to do this:
(defun comment-or-uncomment-region-or-line ()
"Comments or uncomments the region or the current line if
there's no active region."
(interactive)
(let (beg end)
(if (region-active-p)
(setq beg (region-beginning)
end (region-end))
(setq beg (line-beginning-position)
end (line-end-position)))
(comment-or-uncomment-region beg end)))
So I see absolutely no reason for not coding this up and using it :) (Other than, heck, it really is my first ELisp function and it shows :D)
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.)
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.
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...
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?
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.
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.
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.
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.
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.
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.
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.
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).
I'm a recent CS graduate, who only used IDE-s and Sublime Text so far. I have only heard about Emacs and vim when I started my internship. I tried it but it didn't really felt good using it.
Can somebody tell me what are Emacs' benefits over IDE-s and ST for example?
Emacs is extremely extensible. Some people use it as-is out of the box and are happy with it, others treat it more like a framework for creating text editors.
Sublime has plugins, but it's nothing compared to the Emacs ecosystem. I can edit code in one pane, manage my git repository in another, have a terminal to run tests in a third pane, chat with a co-worker with Jabber in another, and look up documentation in a browser (w3m) in yet another pane. The merge conflict resolution capabilities in Emacs are also pretty excellent. I'd say they're at least on par with Vim's excellent Fugitive plugin.
Org mode is a thing of beauty. You can write notes (and enable spell checking in the buffer), create TODO lists, spreadsheets, calendars, handle time tracking, and even embed executable snippets from various languages. The coolest Org mode story I've heard is about Avdi Grimm. He wrote a Ruby book in Org mode and embedded his code right in it. With a single Emacs command he could extract the code from the book and run specs against it, and also package the whole thing up as an ebook.
The learning curve doesn't have to be as brutal as depicted in the blog post. I've only been using Emacs for 4-5 months, and I'm already very efficient with it. I've changed a lot of the keybindings to match what I'm already familiar with, so I didn't learn Emacs as much as I made Emacs learn me.
I used Sublime for years before my switch to Emacs (with a 3 month layover in Vim Land). Sublime is really easy to use, and I still recommend it for designers who write a bit of code, people new to programming, and people who just aren't interested in learning new tools. That said, I spend 90% of my time writing code, and it's great to have an editor that can trivially be made to do whatever I want it to.
An addition to great points already made in this thread- in Emacs it might take a while to set up your environment to your liking but once you have done it you can use it for _everything_. From writing code to managing your agenda to writing haikus. As a user of Dvorak keyboard layout that alone is invaluable to me since I always have my shortcuts optimized for Dvorak no matter what I'm doing.
The default-installed package management system on emacs is fantastic. You generally have to include more sources to get a lot more packages (marmalade), but it's way better than Vundle/Pathogen.
Also, IMO the real driving force behind why emacs is the best browser is the rejection of modality that was the norm (of the time).
I think a lot of people would find it ridiculous if they entered their favorite IDE and were forced into a modal scheme for text entry.
After using vim for a while by recommendation of acquaintances, I decided to give Emacs a try on Windows and GNU/Linux. I've found that it's quite enjoyable, even though I'm too lazy to customize it extensively. It has a lot of nice things already built-in. I would say it's the best FOSS text editor on Windows, at least.
I tried emacs a few years ago when the peepcode on it came out. It's a full blown OS with a text editor! I managed to get my work done, but it wasn't for me. I went back to Textmate for another few years, and am now happily using vim with tmux. I might try emacs again in the future.
Yet another user who thinks emacs is about the key cords. It's not, it's about extensibility. I changed most of the default key bindings, because they were inconvenient.
Remember: Emacs should adapt to you, not the other way around. That's what Emacs is about.
Some people even use VIM bindings in Emacs: http://www.youtube.com/watch?v=Uz_0i27wYbg