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.

m33lky
  • 297
  • 3
  • 9
  • 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
  • What do you mean by "simplify the kill-ring"? How would you do it, and what would you expect to gain from it? – Stefan Mar 31 '17 at 18:26
  • I have edited my question. – m33lky Mar 31 '17 at 19:26
  • 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
  • @Dan Exactly, I'm used to clipboard buffer in Windows/Ubuntu. Can I have that instead of the kill-ring? How is it related to undo-tree, e.g. what is undo-tree based on internally? I'm assuming that undo-tree is separate from the kill-ring. However, when it comes to editing workflows it seems that undo-tree is sufficient: it will help me avoid losing work. So, I don't need the complicated kill-ring. – m33lky Mar 31 '17 at 19:48
  • Please edit that into your post. However, let me suggest you narrow the question down to the part about "can I get Emacs to do undo/redo the same as in other programs" and leave out the other parts about the `kill-ring` and `undo-tree`. We try to keep the questions as discrete as possible here, and you're more likely to get an answer for a narrow and well-defined question than a broad and open-ended one. – Dan Mar 31 '17 at 19:53
  • @Dan I've narrowed down the question. I left the `undo-tree` reference, because that's how I see it relate to the problem at hand. – m33lky Mar 31 '17 at 20:00
  • I edited the question to try to clarify. I should warn, though, that it's still not 100% clear what you want to do, so it might get closed again for being unclear. I think there might be some confusion about what the [`kill-ring`](https://www.gnu.org/software/emacs/manual/html_node/emacs/Kill-Ring.html) is and does, and the same for [`undo-tree`](https://www.emacswiki.org/emacs/UndoTree). I'd suggest reading up on them (see the links to get you started), and then see if it helps in posing the question. – Dan Mar 31 '17 at 20:08
  • @Dan You misunderstood me. I'm not looking for a linear undo/redo at this point. I find it confusing that the kill-ring contains multiple items compared to a simple clipboard buffer. – m33lky Mar 31 '17 at 20:20
  • 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
  • 1
    Um, you do lose something, the quoted scenario explains what exactly. `undo-tree` won't help you with a clobbered clipboard, whatever has been there is permanently gone. With the kill-ring, you can just press `M-y` after `C-y` and retrieve it again. – wasamasa Mar 31 '17 at 20:32
  • 1
    Also consider using Helm's [`helm-show-kill-ring`](https://github.com/emacs-helm/helm/blob/v2.5.4/helm-ring.el#L473), which visually presents kill ring elements and allows searching through elements. – Tianxiang Xiong Mar 31 '17 at 21:02
  • 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
  • I see that no one has mentioned the `browse-kill-ring` library https://www.emacswiki.org/emacs/BrowseKillRing You may enjoy taking a look it it as it will demystify what is contained in the kill-ring, and present you with a nice buffer and overlay options to insert previous kills. – lawlist Apr 01 '17 at 20:09

4 Answers4

7

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.

glucas
  • 20,175
  • 1
  • 51
  • 83
  • 4
    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 01 '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 01 '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 02 '17 at 09:46
  • @m33lky Being able to copy several things in succession and paste them in succession is definitely useful, and as others have said, shouldn't get in the way if copy/cut were the only commands pushing stuff to the kill ring. The choice made that deleting a word, a line, or [comments](http://emacs.stackexchange.com/q/5441/184) instead means to cut them is, I agree, not a very nice default. On the other hand, most "new user" commands, such as using delete for a char or backspace for a region, will "just" delete, not cut. ... – T. Verron Apr 02 '17 at 10:43
  • ... Maybe the idea is that `C-k` or `M-d` are advanced enough that users will be used to the kill ring by the time they get there. Did you identify a command/key in particular which is messing with the kill-ring in your workflow? Maybe it is possible to suggest an alternative or tweak it to leave the kill ring alone... – T. Verron Apr 02 '17 at 10:44
  • @m33lky I don't yet understand what you want to change. If the issue is that Emacs stores more than one bit of cut/copied text at a time, then others have already said you can set the size of the kill-ring to 1. If that is not the answer you want, can you tell us why? As for why storing more than 1 bit of text might be useful: clipboard managers allowing multiple bits of text to be stored are available as extensions on pretty much every desktop and mobile OS. The MS Office clipboard currently stores 24 entries. It's useful because you don't have to re-copy text when you need it again. – glucas Apr 02 '17 at 11:39
  • 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 02 '17 at 12:12
  • If you want a way to delete text that doesn't put it on the clipboard, use `delete-region`. You can also select text and hit backspace to delete (not kill). If you want a command to delete the rest of the line or the next word or some other specific thing without saving it it the kill ring, we can help with that too -- just not sure which of these things you are looking for. – glucas Apr 02 '17 at 12:21
  • @glucas I'm looking for something that is most similar to a clipboard in other systems. You can only paste what has been copied or cut, and paste takes the most recent item. In this case multiple items in the `kill-ring` is not an issue. Now I need to check whether `simpleclip` makes this possible, or if I have to modify delete keys, so that they don't put things into the kill-ring. – m33lky Apr 02 '17 at 12:43
  • 1
    @glucas `simpleclip` meets my requirements. Thank you for your patience. – m33lky Apr 02 '17 at 18:56
  • I'm glad you found something that works! You may want to give @phils answer the check mark here since he suggested simpleclip and provided a more concise answer. – glucas Apr 03 '17 at 15:08
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.

phils
  • 48,657
  • 3
  • 76
  • 115
  • 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 01 '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 01 '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 01 '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 01 '17 at 11:49
  • And as answered here you can ignore `yank-pop` and will never notice the rest of the kill ring. You can remove the M-y binding to avoid confusion. – glucas Apr 01 '17 at 12:10
  • @m33lky, I *think* you're ultimately objecting to there being multiple ways to kill things? However that's for the good reason that there are multiple different kinds of things to kill. A word, a line, a sentence, a paragraph, a balanced expression, a comment, a marked region. – phils Apr 01 '17 at 12:46
  • 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 https://github.com/rolandwalker/simpleclip which might suit your needs. – phils Apr 01 '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.

stevoooo
  • 737
  • 3
  • 8
  • 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
0

In summary: To "enable" a Windows clipboard-like behavior is to disable the ability to retrieve previous deletes up to N-level deep (ie. set the kill-ring-max value to 1). To do this, add the following line to your Emacs init file...

(setq kill-ring-max 1)  ;; Note: Set to (eg.) 60 to re-enable this feature
algn2
  • 31
  • 2