0

How can I get Emacs to behave the same as other programs for copy/paste (i.e. OpenOffice, Microsoft Word, etc.)?

I want to simplify the kill-ring so that it behaves like a simple clipboard. I find it complex that the kill-ring contains multiple items.

In my understanding I don't lose any of my work by doing this, since I have undo-tree to help me keep a history.

Quote from Emacs tour:

Recall that most commands which delete a large amount of text in fact kill it (i.e. place it in the kill ring) so you can restore it later. Emacs makes it very difficult to lose a lot of text permanently: in editors with only a single clipboard, one can easily accidentally delete a large chunk of text or clobber the contents of the clipboard (by cutting two items in succession). But in Emacs, in either of those cases, the lost text can easily be retrieved from the kill ring.

Please tell me how to do this. You can also add your reasoning why I shouldn't do this, or under what (infrequent) circumstances this scenario occurs.

  • 3
    The question is not very clear. What do you mean by "should" you? What behavior are you looking for? What's the real question? – Drew Mar 31 '17 at 17:38
  • 1
    undo-tree replaces the (linear) undo system of a buffer with a tree, the kill ring is a separate thing that's always of linear nature and holds your last kills. This question doesn't make any sense. – wasamasa Mar 31 '17 at 18:13
  • 1
    Let me suggest that you edit your question again to lay out a) how you see a "simple clipboard buffer" working, b) how the kill-ring and/or the undo-tree differ from what you expect. It's not obvious yet what you're trying to do here when you say you want to "simplify" the kill-ring. Do you mean you want Emacs to behave the same as other programs in how it handles undo/redo? – Dan Mar 31 '17 at 19:39
  • 3
    You can control the size of the kill ring with the kill-ring-max customizable variable. Does setting it to 1 replicate the "simple clipboard" you want? – Tianxiang Xiong Mar 31 '17 at 20:22
  • 2
    Is there some actual scenario where the kill ring is causing you problems? It seems to me that unless you explicitly invoke yank-pop to access older entries in the kill ring, it should already behave like a 'simple clipboard': the various kill commands save an entry and yank restores it. – glucas Mar 31 '17 at 22:32
4

From the various comments so far, it sounds like you are in the process of learning about Emacs (welcome!). There are many things in Emacs that are unlike other editors, and as you go through the tutorials and read about things you might come across concepts like the kill ring that seem confusing and/or unnecessary.

Emacs is endlessly configurable so you can bend it to your workflow, but I would always recommend you experiment with its features before trying the change something. You might find something that seemed weird is actually really useful -- or that it isn't, but now you've got enough experience to know exactly how you would like it to work.

In this particular case it seems like you are worried about the complexity of managing the kill ring, but perhaps have not used Emacs kill/yank commands frequently enough to see that it does not gets in the way or require any specific workflow: this is a feature that is invisible until you ask for it.

If there are specific problems you've encountered (such as accidentally hitting M-y and yanking the wrong text) then add those to the question and they can be addressed directly. You can change or remove the binding for yank-pop if it gets in the way of something else.

Updated

Based on the comment threads, it sounds like the real concern here is not the kill-ring but rather the various kill commands.

In many editors: C-x will cut the selected text, and C-v will paste the most recently cut text. In Emacs: C-w will cut the selected text, and C-y will paste the most recently cut text -- same thing.

In many editors, you can select some text and hit backspace to delete that text without saving it anywhere. In Emacs you can do the same thing.

The difference is that most editors have only one command to cut text. Emacs has that, but also has commands to cut things without having to select them first: the rest of the line (C-k), the next word (M-d), a sentence, an expression, and so on. These are variations of the cut command: use any one of them, then use C-y to paste the most recently cut bit of text.

For every cut (kill-) command in Emacs you could define another command to do the same thing without saving to a clipboard. For example you could have delete-line, delete-word, delete-sentence, delete-sexp, etc. Then you have the choice to delete or cut anything you want -- but you double the number of commands and key bindings, and every time you want to remove some chunk of text you need to decide whether you want to save it for later.

The Emacs approach is to provide the "cut" versions of all these commands, but to maintain a longer history. You can freely cut text in many places and will be able to find it and paste it again if needed. Otherwise you can ignore the history and always paste the most recently cut text using C-y, as usual.

Other editors I'm aware of don't (ok, ignoring vi[m]) have commands to delete up to the end of the line or sentence, delete the next expression or next 3 words, etc. You would do that by highlighting the text and then either hitting cut or backspace -- which you can do in Emacs too. So asking for these special commands to behave as they do in other editors is confusing: they don't exist elsewhere. If you want to use them, it's worth trying out the default behavior before deciding it is too complicated. If you end up deciding this is really not what you want, it is fairly easy to define new delete-xxx commands that are similar to the kill-xxx commands you actually find useful.

  • 2
    Oh, it most definitely gets in the way. E.g copy a chunk of text, then delete a couple words with M-d and paste what you copied there... Woops, you just pasted the last word you deleted instead. (Not sure if that's the specific problem the OP encountered) – T. Verron Apr 1 '17 at 18:56
  • Yeah, that may be what the OP is really asking. To me that isn't really about the kill-ring -- rather it's about al the different ways to kill text -- but I can see the confusion. – glucas Apr 1 '17 at 19:21
  • @T.Verron These are the kinds of things I'm referring to. In my view buffer should be only for what I cut or copy one item at a time. In the Emacs world I have to think about what gets killed. I keep getting requested to learn more about Emacs, but no one has yet explained why this particular Emacs workflow is advantageous. I understand that Emacs is configurable, and I am trying to get back to what seems to me like a standard and simple set of defaults known in other systems. – m33lky Apr 2 '17 at 9:46
  • 1
    If what you want is a stand-alone command to save text to some dedicated clipboard and another to paste it, then @phils earlier comment to use a separate package like simpleclip sounds like exactly the right approach. Then you can ignore the kill-ring altogether. – glucas Apr 2 '17 at 12:12
  • 1
    @glucas simpleclip meets my requirements. Thank you for your patience. – m33lky Apr 2 '17 at 18:56
6

I want to simplify the kill-ring so that it behaves like a simple clipboard. I find it complex that the kill-ring contains multiple items.

You can completely ignore the fact that the kill ring contains multiple items if you want. If you only ever use yank (C-y) to paste, then you will only ever paste the most recently-killed text.

Unless you actively tell Emacs to yank text from elsewhere in the kill-ring, it won't do that, and so you needn't care that the rest of the kill ring exists.

i.e. In systems with a single-item clipboard, the paste command always pastes the most recent copy/cut text, because that is all that it can do. In Emacs the yank command also pastes the most recent killed text, but if you explicitly ask it to it can give you something different.

I think the only thing which could trip you up is the variety of commands that kill text (therefore changing what is on the front of the kill ring). There isn't just a single 'cut' command in Emacs, but a whole array of kill-* commands with standard key bindings. Hence you might manage to add some text to the kill ring inadvertently after an intentional kill, and then be surprised that your next yank didn't give you the text you were expecting to get.

I really would urge you to familiarise yourself with the kill ring concept, rather than trying to limit it. I've heard plenty of people bemoaning the lack of a kill ring outside of Emacs, but I think this is the first time I've ever heard of a person wishing that Emacs didn't have one either. I genuinely think you're doing yourself a disservice if you try to avoid it.

  • Under what scenario does kill-ring help where undo-tree history won't? To me it seems like a convoluted feature. If my workflow is to use a simple clipboard buffer and undo history, then how can I lose work? That's what I care about. Like you mentioned there are multiple Emacs commands that put things into the kill-ring. I see very limited use for such behavior, and don't see the benefits of adopting a workflow with a kill-ring. – m33lky Apr 1 '17 at 11:04
  • Undo is for returning the buffer to a previous state. Killing text and later Yanking it from the kill ring is for editing the buffer into a new state. I don't understand how undo helps you in any situation where you want to paste some previously copied/killed text. If you kill two things and later on, after other editing, you want to yank them both back, how would undo be of any assistance? – phils Apr 1 '17 at 11:27
  • 1
    @m33lky It is still not clear (to me at least) what about your workflow would change to use the kill-ring vs. not use it. As @phils points out in this answer you can choose to never access anything except the most recent entry in the ring, which seems identical to any other clipboard. What exactly are you objecting to? Also note that the kill-ring in Emacs stores copied text as well as cut text. You can copy 5 things from different buffers, then paste them all in another buffer -- undo is totally unrelated. – glucas Apr 1 '17 at 11:41
  • @glucas I have a simplistic workflow where I use a one-item clipboard. The quote from the guided tour presents advantages of the kill-ring. It doesn't strike me as important, because I only consider changes to the file worthy. I am objecting to the functionality of the kill-ring where inadvertently I run a command that changes the order in the kill-ring and it stops behaving like a one-item clipboard. – m33lky Apr 1 '17 at 11:49
  • 2
    I suspect your best option is to have an alternative set of copy/cut/paste commands which maintain their own clipboard independent of the kill-ring. A brief look in MELPA turned up github.com/rolandwalker/simpleclip which might suit your needs. – phils Apr 1 '17 at 12:55
0

Have you tried using Emacs' cua-mode? This sets up key bindings that are compatible with the Common User Access (CUA) system, so C-x, C-c, and C-v behave as they do in those other applications. I believe it should give you the behaviour that you're after.

  • I have been reading up on it. It seems to be quite "invasive" in terms of changing key bindings and behavior. You're right that the code there probably has a solution to what I'm trying to achieve. – m33lky Mar 31 '17 at 20:25
  • Well, Emacs has its own terminology and way of doing things which is often quite different to what has since become common in other software. I suppose you have to choose whether you want to change Emacs to work like everything else (which is entirely possible), or whether it's worth getting to know Emacs on its own terms. Personally, I'd recommend getting to know the Emacs way of doing things first, but YMMV of course :-) – stevoooo Mar 31 '17 at 20:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.