Because vim's paste command, p, will paste what was last removed with a command (such as d or c).
Although you're not explicitly told that d and y are analogous to cut and copy, after learning the mechanics of p, each command you learn adds a new (and powerful!) mechanic which doesn't have a parallel in the normal cut/copy/paste model.
For me, p is for pasting between open buffers, and <leader>p is for pasting between programs. This way you can paste from an open buffer, and paste from the system clipboard with no go-between.
vimrc:
" copy to clipboard
map <leader>y "+yy
" paste from clipboard
map <leader>p "+p
Which is pretty counter-intuitive: it's "copy", then "paste but delete the original"? Much more natural to remember ?-c, ?-delete, change folders and ?-v.
A, B) I'm not sure I did a good job illustrating with my example. But there are times when the new text needs to appear above the text I copied. In that case, I'll take extra effort to paste the section to edit above the existing, to make sure I'm editing the "new" text. Even if it takes a bit more effort to position my cursor above the copied text.
So in vim, I might yank an entire line and paste it immediately ("yyp"). This automatically pastes below the yanked line and positions the cursor on the new line. But let's say I want to make the edit above the existing. This situation is wrong. The new line was just pasted below the existing. Even though I'm looking at a pair of perfectly identical lines in the file, and could make my edit wherever I choose, I have this idea that one of those lines is the original and the other is the copy. And I don't want to edit the original. In other words, whether I "do it wrong" or "do it right", the end result will be bit-for-bit identical. But one of those edit paths bothers me and the other one doesn't.
So in the yanking and pasting process, I'll take the extra time to move my cursor above the copied line, then paste it in so as to preserve the "lineage" of the text.
This has nothing to do with version control or any other actual efficiencies. It's just my brain being weird. I don't gain any actual benefit, just a calm mind :)
C) Yeah, I was just heading off any nitpicks about my comment.
As mentioned elsewhere, if your vim is compiled with clipboard support(:version and look for +clipboard), you can copy/paste from the clipboard.
* is the Linux selection register.
+ is your clipboard.
So yanking is just set paste, "+y or " * y, set nopaste. Similarly you can do a "+d in vim and ctrl-v it in your browser or anywhere you can access the clipboard. You can " * d/" * y and paste it with your middle mouse button.
It's true, but since vim is a bit old, copy/pasting can be a bit awkward due to having an internal clipboard with the buffer and not using the system's clipboard.
I wouldn't put that in a beginner tutorial (at least the system clipboard copying/pasting).
Using the distinction of paste as copy vs paste as move, instead of overloading the cut metaphor is a better choice semantically. When you cut text or images from a document with ctrl/cmd-x the content is deleted immediately. It’s weird and inconsistent that in windows the files get greyed out and if you don’t paste them they... eventually look normal again when you put something else in the clipboard? Modifying the paste with option on mac is also consistenT with option switching between move and copy while dragging files.
Yeah, but then you're stuck counting lines. Whereas with a mouse, you just click and drag exactly what you want.
"p (vs. right-click > 'Paste')"
This is more difficult if you've copied whole lines but want to paste inside a line or replace text with your paste.
I love me some vim, but I do think it's easy to think we're faster than we are. I wonder if I recorded myself and then watched it if I'd think I was as fast as I feel that I am.
The problem with keyboard or menu cut/copy/paste (hereafter c/c/p) is that it’s a mode (or at least a sort of quasi-mode), and modes are a fundamentally inhumane user interface approach that shift cognitive burden from computers to humans. The traditional c/c/p includes no visual feedback whatsoever, is an extremely overloaded concept (many types of objects can be copied, the result of pasting depends on context and there’s no way to tell precisely what will happen from past experience with other applications, sometimes a copy instruction only places a link to the content (for performance reasons) so that closing a document or application alters the paste behavior, c/c/p between applications is often brittle, especially when dealing with rich text), and is very limited and inflexible (no way or bad ways (depending on the implementation) to copy two things and then paste them back, copying another thing destroys the user intent of the previous copy operation and can’t be undone, no visual/spatial context is provided for the operation, etc. etc.).
C/c/p is better than what came before it (it was invented at PARC in the early 1970s, and the alternative was much more mode-ful, something like vim), but is still too unfriendly for novices and too limited for experienced users. Unfortunately, it is so ubiquitous that it has forced all users to learn it, forced all software to implement it, and crowded out alternative approaches, even in contexts like file managers where the concept doesn’t really make sense. The best we can typically hope for is extensions of the typical c/c/p interaction which work like other implementations in the simple case but have some extra functionality for experienced users. These are usually entirely undiscoverable, and still share most of the problems of the traditional c/c/p.
Though I understand that this is just an example of the power of `!r`, readers should know that VIM in fact can copy to the system clipboards natively.
I think this is a logical approach to pasting. In Windows, for example, if you start by cutting the file, then navigate to where you want to paste it to, and change your mind, deciding you actually want a copy but to keep the original where it is, then you have to start the operation again from the beginning.
With macOS, you can decide whether to `mv` or `cp` just by pressing a modifier in the destination directory.
But, again, this isn't really cut and paste at all. It's more like "note position, and _then_ atomically cut and paste". Cutting and pasting files in Windows doesn't work at all like cutting and pasting anything else.
Someone who had never used Windows might reasonably expect, on finding 'cutting' a file did something, that if they never pasted the file would just be deleted, because that's how cut and past normally works.
Its not. You usually do most of your copying and pasting within vim so you can just use the normal past command, but it is annoying when you want to do something with the system clipboard.
reply