Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Nothing to do with Unix, it's an Emacs thing.

In Emacs, what you nowadays call "cutting and pasting" is instead called "killing and yanking". It was called that way even before "cut" and "paste" got popularized, I think.

And the "Kill Ring" name makes sense, as it a) contains snippets of text you killed and b) when yanking (pasting) lets you cycle through all the killed snippets. You can view your kill ring in its entirety via a menu or with a plugin (kill-ring-browser or similar, I forget).

Emacs is old and brittle, but its basic editing model is very good. It does lack (without plugins) some features I learned in Vim (the most irritating thing at the beginning was a lack of "textobjects"; I still occasionally miss them, despite expand-region and other plugins), but is basically the only editor that I feel is worth learning.



>>In Emacs, what you nowadays call "cutting and pasting" is instead called "killing and yanking". It was called that way even before "cut" and "paste" got popularized, I think

Cut and paste refer to literal scissors/knives and glue/paste it predates the Gutenberg press.


Emacs is based on arcane incantations and Elder horrors. It predates creation and sanity. :p


Ok, I stand corrected. And it seems rather logical, too.

So where do "kill" and "yank" names come from?


> So where do "kill" and "yank" names come from?

This is discussed a bit on ESE, though the explanation seems vi-centric: http://english.stackexchange.com/questions/40657/how-yank-ca... .


One of the crazy aspects of Unix text editors is that "yank" means nearly the opposite in vi (where it stands for copying) as it means in emacs (where it stands for pasting).


First time I heard that yank means "yanking from the buffer" I figured I'd had a mini stroke.


> Nothing to do with Unix, it's an Emacs thing.

Yes, I know that. It was a joke that used the specific example of Emacs to illustrate a point about how tone-deaf Unix developers can be about UI issues.

> In Emacs, what you nowadays call "cutting and pasting" is instead called "killing and yanking". It was called that way even before "cut" and "paste" got popularized, I think.

Sure, but it's been pretty much universally referred to as "cutting and pasting" everywhere for what, two decades now? The Emacs terminology is a wart, a relic of a bygone age. There's no reason to continue using it, except inertia.

> And the "Kill Ring" name makes sense, as it a) contains snippets of text you killed

This only makes sense if you accept that there is a reason to continue referring to that interaction as "killing" rather than "cutting", which (as is probably clear from the above) I do not. The world has settled on a set of terms to describe these interactions, persisting in using ancient ones just because they're what have always been used just makes Emacs harder to learn that it should be.

(Which may of course be the whole point; surrounding common interactions with unusual terminology is a good way for people who already know Emacs to state to outsiders that they are keepers of arcane knowledge beyond the common ken of man. But social signaling is a shabby motivation for user interface decisions.)


Inertia has a way of preserving value in a way that's easily overlooked. Consider the "save" icon - still commonly represented as a floppy disk even though there's an entire generation in the workforce that grew up without ever touching one.

It would almost cost more to change it (just in lost productivity) to be "correct" than it would be to just keep the association. I think the same is true for the editors.. changing the terminology would also mean changing a lot of mnemonics. Vim uses D and Y for kill (delete) and yank. C is already bound to another function, and there's an ambiguity there between "C"ut and "C"opy. (P is "P"aste, as you'd expect)

Just because you're unaware of the reasons for the design is not good enough reason to dismiss the UI design as "social signaling" and tar the whole of the userbase with that kind of accusation. It seems you have an axe to grind against those SmugEmacs(Lisp)Weenies[1] :)

[1]: http://c2.com/cgi/wiki?SmugLispWeenie


> changing the terminology would also mean changing a lot of mnemonics. Vim uses D and Y for kill (delete) and yank. C is already bound to another function, and there's an ambiguity there between "C"ut and "C"opy. (P is "P"aste, as you'd expect)

You corrected the Vim key (D instead of K), but now it doesn’t support the conclusion. Cut, copy, and paste are already typically bound to Ctrl+X, Ctrl+C, and Ctrl+V, which people seem to use fine without mnemonics. Does anyone actually think “hmm, which key is it to yank text in Vim? Ah, right, y for yank”? (Well, probably, but I imagine they’re the minority.)


> Cut, copy, and paste are already typically bound to Ctrl+X, Ctrl+C, and Ctrl+V, which people seem to use fine without mnemonics.

I think it's like this: for the most often used functions it's more important to make keybindings convenient to press (your keyboard and the shape and size of your hands matter here!) than memorable/backed with mnemonics. The idea here is that you're going to be using them all the time, so you'll remember them anyway, no matter how "unintuitive" they seem. Functions used less often, on the other hand, should be bound to something that is guessable and/or easy to remember.

A side effect of this is that, once you set everything that way, you're going to be bound to a particular (physical) keyboard model. I accept this lock-in, because I spend half my life typing on a keyboard and I'm picky when buying keyboards anyway.

A couple examples: screen uses C-a while tmux uses C-b as a prefix key. The first thing I did after switching to tmux was to remap the prefix key back to C-a (with C-a C-a standing for normal (readline) C-a), not because I was that used to C-a, but because (again, on my keyboard) pressing C-a is easier done with one hand.

In StumpWM C-t is used as a prefix by default. I immediately remapped it to C-z (with C-z C-z representing normal C-z) for the same reason.

In Emacs, one of the first customizations I did was to pack all window-related commands under C-w prefix ('w' like in 'w'indows...). C-w C-s now means 'w'indow 's'plit, C-w C-v 'w'indow split 'v'ertically and so on. Here the chords are both easier to type than the original bindings and easier to remember.

As programmers we spend 1/3 of our lives (at least, I think) working on a computer, and significant chunk of that time working inside an editor. It makes no sense not to customize the tools we use to the point where they are optimal for our particular "setup" (in quotes, because again, I also mean size and shape of your hands, your habits from earlier work, your keyboard and your desk).


I've enjoyed a Vi-emulation keymapping that i made where the primary movement keys are on the home row:

https://github.com/bshanks/viperre

I also use the Colemak keyboard layout, so i made two versions of the mapping, one for QWERTY, one for Colemak. Which highlights the importance of text editors (and IDEs) needing to have completely configurable keybindings.


Vim uses y and p to yank (cut) and put (paste), not K and Y. Of course, there are other ways to yank (Y, d, D, …). Ultimately, at least the y goes pack to the ex command y.


..Now why the heck did I think cutting was on K. D'oh!

Still, I think it's a conscious design decision, something along the lines of "why not just store deleted text, rather than having a separate clipboard-like feature".


Yep, and vi even gives you multiple registers in which to store yanked or deleted text. In vim, you get [a-zA-Z0-9\-"] all as registers! Just type "x where x comes from that character class, to use a non-default register (the default register is ", so if you want to explicitly use the default register when deleting a line, you could do: ""dd ).

It's similar to how marks work, as well.


"Cut Ring" just doesn't have as nice of a ring to it as "Kill Ring".


Modern emacs isn't old or brittle anymore. Heck, we even have text antialiasing now for users with graphical displays! :-)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: