Copying Lines, not killing
emacsblog.org
emacsblog.org
That said, it's a nice tutorial on how to set a global binding. They just should have worked harder on picking a useful example.
(defun duplicate-line ()
"Duplicate the line the point is on, moving the point to the duplicate"
(interactive)
(save-excursion
(kill-new (buffer-substring (line-beginning-position) (line-end-position)))
(end-of-line)
(newline)
(yank)
(rotate-yank-pointer 1))
(next-line 1))
(global-set-key "\M-w" 'copy-region-as-kill)
Emacs periodically surprises me by already having some minor function I wanted, but half the time it's only surprising because it's named something unusual (compared to both other programming environments and the rest of Emacs). I can never remember what the commands are called for "get (point) for beginning / end of line", just that they're named something I can't find by searching apropos with anything that comes to mind, so I use something like
(defun end-of-line-point ()
(save-excursion (end-of-line) (point)))
While, on the one hand, it's nice to be able to extend the editor so easily, solving the underlying problem wouldn't detract from its extensibility in any way. Sticking everything in one namespace also leads to function-with-unnecessarily-cumbersome-name syndrome. (C has the same problem, though.)
Maybe one of these days I'll quit whining and just write another editor, but any real competition to Emacs has a lot of functionality to match, and most of the other historical cruft is easy enough to tolerate.
I was going to post my thoughts on the impossibility of a (require 'sane-emacs) but then I found this document on "Emacs2010": http://code.google.com/p/emacs2010/wiki/DeveloperIntro
I have a strong suspicion that there are various subtle factors in the design of Emacs that encourage people to re-implement things in elisp, rather than just use existing programs. Elisp has external process calls, but it still seems like this blob that turns half of what it touches into something that will eventually be rewritten in elisp. (Perhaps part of it is that Emacs all runs in one thread, so background processes make it freeze.) I know many people love working in Lisp, but I'm pretty sure it's the last Lisp most people would choose under any other circumstances. (I'd rather use Scheme.)
There's a lot of stuff that doesn't need to be running inside the editor. Its core could probably get by fine on undo/history management, file and buffer management, syntax highlighting, a keybinding system, a generic comint-like mode for shells and interpreters, other external process call functions, and ... what else? (Acme & Wily do all of the above except syntax highlighting. I'd use it, but I strongly dislike mouse-centric UIs.) I know that's a fair bit of work, but it's not like one would have to rewrite all of gnus and whatnot. Even something like query-regexp-replace or pabbrev could be an external process.
I've also been wondering if there's a good way to make the parser system used for syntax highlighting separate, but haven't settled on anything yet. (Parsing text that is changing as you parse it is a fundamentally different problem than parsing a static file or stream, and a relatively unexplored one, as this blog post notes (http://www.codekana.com/blog/2009/04/02/on-the-speed-of-ligh...).)
Finally, I think that Lua would be an excellent choice for the customization language. A lot of Emacs's warts are ultimately issues with elisp, itself. (And, while Lua is my favorite language, and I'm admittedly biased, such use as an extension language is one of its major strong points.)
Vim is the kind of editor that never makes you type three characters where one would do. Or delete some text and then paste it back as the only means to 'copy.' It's about efficiency down to its bones.
Now, I'm well aware these things are customizable in emacs, but they're shipped as defaults. This implies the community thinks they're best, and belies a mentality that I just can't get with ("more keystrokes? no problem").
In some cases, it just serves as a reminder about Stallman's incredible stubbornness. (transient-mark-mode, for one) The defaults are easy to change, at least.
Also, not to feed the trolls, but it seems like with Emacs vs. vim arguments, people are usually talking past each other. In general, it sounds like Emacs users are happy to have an easily extensible environment, and the vim users enjoy using such a terse and efficient text editor.
There's nothing contradictory there!
An editor could do both, there just hasn't been a sufficiently popular synthesis of their strong points, yet. (Right?)
But as a vim user, I like the way that vim works with minimal configuration. Yes, I could configure emacs to behave any way I'd like -- in fact, I generally like doing that sort of thing -- but as long as I'm really configuring my editor, I don't want to start with a horribly messy system like Emacs (and Elisp -- dynamic scoping?). Not to mention that I can't stand the default keybindings, and all sorts of extensions aren't quite as friendly to set up once you've deviated from the defaults significantly (such as in VIPER).
Vim may be a "temporary" solution for me in that it's not as configurable as I'd like (I don't like Vimscript either, but I don't use it!). However, as "temporary" solutions go, it's very good at what it does (editing text, and that's it). I wouldn't dream of running an IRC client inside it, though.
Some people like to easily have their editor do a lot of stuff for them, some people would rather do a lot of stuff in their editor easily. There are vi modes for emacs and vim has a pretty good scripting language for add-ons (ain't no emacs though).
I've heard of at least one project that aims to do both, but that one's written in Haskell, so you'll probably not have all that many people using it anyhow.
http://www.emacswiki.org/emacs/key-chord.el
It lets you bind commands to "chords." For example, I bind pressing U and I at the same time to 'other-window (typically, C-x o).