
Copying Lines, not killing - twampss
http://www.emacsblog.org/2009/05/18/copying-lines-not-killing/
======
almost
Doesn't that just replace C-kC-y with C-cC-k? Given that C-cC-k is used by
various major modes to do mode-specific killing this doesn't seem like a good
trade.

~~~
ajross
I was just about to point out the same thing myself. This is just dumb -- you
add keystrokes to save typing or to simplify a metaphor. This complicates the
metaphor (decide between cut and copy), saves nothing (actually it's harder to
type for those with ctrl bound properly -- K/Y can be done with two fingers of
the same hand), and pollutes the space of key bindings to boot.

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.

------
randrews
I had this same problem, and I solved it thusly:

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

I'm sure there's a better way to do that (this is one of the first elisp
things I ever wrote), but the general idea is that you duplicate the line the
point is on, and then move the point down one line. It's surprisingly useful,
more so than copying a line to the kill ring.

------
aristus

        (global-set-key "\M-w"  'copy-region-as-kill)
    

There's a core Emacs function that does this. It's confusingly called copy-
region-as-kill, and it's bound to C-INSERT and f16 by default. I bind it to
Meta-W.

~~~
silentbicycle
This is one of many reasons I wish Emacs lisp had a reasonable namespace
mechanism, rather than just a somewhat haphazardly applied verb-noun naming
convention. Copy/kill/yank/etc. commands could be collected, movement commands
together, etc. (Even if only aliases.)

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

instead.

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.

~~~
aristus
Imagine a 20-minute song that had to contain a riff from every musical fad
from the end of the Carter era to the present. :)

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>

~~~
silentbicycle
See, my biggest problem with Emacs is, why should adding all that
functionality to the editor mean _rewriting all of it_? There are _existing_
programs that do most of those things already, and many of them are written in
languages better-suited to those specific tasks. Seriously.

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...](http://www.codekana.com/blog/2009/04/02/on-the-speed-of-
light-innovation-and-the-future-of-parsing/)).)

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

------
r00k
Honestly, this was one of emacs' defaults that caused me to give it up and go
back to vim. Also being forced to type out 'yes' completely to quit.

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

~~~
silentbicycle
> This implies the community thinks they're best

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

~~~
shachaf
Well, there's VIPER...

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.

~~~
silentbicycle
I agree with you on pretty much all counts, actually. While one can use viper,
most modes people have written follow the conventions for Emacs keybindings,
so it's ultimately pretty futile.

------
jderick
While we are on emacs, check this out:

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

------
jcapote
Whats wrong with highlighting a region, and doing M-w on it, then yanking it
back in?

~~~
mannicken
C-space, C-e, M-w. Three freaking commands.

