There is no bug here. Since I was also annoyed with this behavior, I just read Evil code to find out why this is happening. So, here is a straight copy/paste of the well-commented one-liner from my Emacs configuration that fixes this issue:
;; Imagine the following scenario. One wants to paste some previously copied
;; (from application other than Emacs) ...
"Yank" is just English. You are "pulling" some text into the current buffer at point.
Note that the more common term "paste" (no, it is not quite the same thing) is no clearer in this regard. There is no glue involved.
Note too that the verb "copy" has two meanings that can confuse its use. One of them means to make an invisible copy, which can later be ...
Use M-x picture-mode. C-c C-y, bound to command picture-yank-rectangle, does what you want. (You can use C-_ to undo.)
These related keys are also available in picture-mode:
C-c C-k - Clear a rectangle and save it (picture-clear-rectangle)
C-c C-w - Clear a rectangle and save it in a register (picture-clear-rectangle-to-register)
C-c C-x - Like C-c C-y, ...
This is from 12.2.2 Yanking Earlier Kills:
‘M-y’ can take a numeric argument, which tells it how many entries to
advance the “last yank” pointer by. A negative argument moves the
pointer toward the front of the ring; from the front of the ring, it
moves “around” to the last entry and continues forward from there.
avy already supports what you want. See avy-dispatch-alist.
However, the default actions are not enough. I have the following function in my config (here it copies a sexp, but you can change it to copy a line):
(defun my-avy-action-copy-and-yank (pt)
"Copy and yank sexp starting on PT."
Then assign a key to the function ...
Starting at the beginning of line 4 (ESC 4 ESC g g or M-4 M-g M-g to go there), C-3 C-k C-2 C-n C-y (or ESC 3 C-k down down C-y if you don't like holding modifiers down) will do this.
If you don't want to do the arithmetic in your head, but instead select lines visually, then
Move to the beginning of the zone to move
C-SPC to set the mark
Move down to the ...
The package https://github.com/Lindydancer/highlight2clipboard does exactly what you asked for. It use htmlize to create a HTML version of the text which it adds as an alternative paste text. (Note: This is a non-trivial operation which requires interfacing with the clipboard. This is operating system specific, currently OS X and MS-Windows are supported.)
The htmlize package can do this. Install it with M-x package-install htmlize and you get access to the commands htmlize-region
(htmlize-region BEG END)
Convert the region to HTML, preserving colors and decorations.
(htmlize-region-for-paste BEG END)
Htmlize the region and return just the HTML as a string.
This forces the ‘...
The suggestion in @gongqj's answer changes the behavior of paste so that cut text (via d) no longer gets pasted. This does not seem like what you want given your comment:
Ideally pasted over text is not added to the kill ring but we get
killed text (not from pasting over, i.e. D) then it'd be nice to
paste that on visual state paste.
If your real ...
Here is a one-off command you can use to yank the each line of the current kill on the end of each subsequent line, starting on the current line.
(defun yank-append-lines (&optional without-space)
"Yank each line of the current kill at the end of each subsequent line.
A space will be added between each line unless WITHOUT-SPACE which can
be passed in ...
TL;DR: you can use clipmon available on MELPA, and turn on clipmon-mode.
Note: the details below apply to X servers, but the package should work on any platform.
How does the clipboard work ?
Clipboard is implemented as an asynchronous process. When you copy from an application, it becomes the "clipboard owner" but doesn't actually put the copied data ...
After yank text1, the text is saved in both register " and 0:
When paste with p, you actually got text1 from register ", at the same time, the killed text is saved in ":
So, if you want paste text1 next time, you should press "0p instead of p, or replace the default key binding:
Some of your parens were in the wrong place. I think you were expecting endp to be updated when you do the replace-match, but it has a fixed value, so I changed it to use copy-marker instead, which will get updated.
(defun replace-in-yank (numstr)
(interactive "sNumber: ")
(let ((repstr (concat "\\1:" numstr "=\\1"))
You'll have to advise yank (to restore the mark after it, and to save the "other end" somewhere) and yank-pop (to fetch the other end from that "somewhere", move the mark to it, then run the original code, and after that, restore the mark again).
You have a few options for this :-
You can use counsel which provides with the command counsel-yank-pop which will show the list of all the yanked text and you can select anyone of them using ivy (this is what I use). In your case, you can press M-> to go the first entry in the kill-ring.
if you use helm, there is the command helm-show-kill-ring which ...
There is no "strange issue" here - just a misunderstanding. The behavior you see is by design.
What you call the "isearch window" is in reality not a window, and it does not display a buffer. It is just the echo area, which is an output area for showing messages to the user. It is not an input area.
If you try to use an ordinary yank (paste) command ...
A fourth option is optimized for ease of yanking, at the cost of a little forethought during the killing phase. We use append-next-kill (C-M-w) before the second and each subsequent kill operation. This means that all the killed text is amalgamated into the same entry in the kill ring. So a single C-y is all that is needed to yank it all back at the new ...
A very rudimentary function that will yank the displayed image at point to the X11 clipboard:
(defun x11-yank-image-at-point-as-image ()
"Yank the image at point to the X11 clipboard as image/png."
(let ((image (get-text-property (point) 'display)))
(if (eq (car image) 'image)
(let ((data (plist-get (cdr image) ':data))
Removing yank-handler text property from just killed text should do the trick, since this will make yank use normal insert instead of rectangle-mark-mode's own insert function.
(defun kill-ring-save--strip (orig-fun &rest args)
(let ((rtv (apply orig-fun args)))
(let ((killed (car kill-ring)))
You can extend your current code to bind [mouse-2] and [down-mouse-2] to nil in flyspell-mouse-map:
(define-key flyspell-mouse-map [down-mouse-3] #'flyspell-correct-word)
(define-key flyspell-mouse-map [mouse-3] #'undefined)
(define-key flyspell-mouse-map [down-mouse-2] nil)
You need to customize the .tmux.conf too in addition to the below customization in emacs.
With the below setup here are few scenarios of how copy-pasting can work between emacs and tmux:
Copy/cut from emacs and paste in shell command line in tmux: Do M-w or C-w in emacs and TMUX_PREFIX C-y in tmux.
Copy from tmux and paste in emacs: Do TMUX_PREFIX C-w in ...
You could use expand-region to mark the block, if it is a semantic unit, like a function (The package's website explains this in more detail). Then moving it around as the other response explains. Depending on where you are in the block, a single keystroke can mark the whole thing.
I'm not sure that it is possible to have copied text appear in your kill-ring immediately after copying, unless there is some way to run a hook on copy. This would obviously depend on your operating system/environment, but I did want to mention that you might want to try setting
(setq save-interprogram-paste-before-kill t)
Which will at least preserve ...
After poking around the helm source code a bit, it looks like helm tries to temporarily override all the mouse commands using the minor mode helm--remap-mouse-mode, and this is most likely the source of your issues.
With the caveat that I don't have any experience with using the mouse in Emacs, there are several solutions that occur to me here, in ...
It seems you could use -1 as a prefix argument to M-y as hinted by the manual:
M-y can take a numeric argument, which tells it how many entries to advance the last-yank pointer by. A negative argument moves the pointer toward the front of the ring; from the front of the ring, it moves around to the last entry and continues forward from there.