Using emacs in console mode, I want to copy mouse selected text from emacs and paste it to another application (possibily another term).

But emacs will add full spaces to the selection to fill the entire width of the screen.

To add insult to injury, vim works perfectly. I had to switch to vim (or cat) to do a simple copy/paste.

As a test scenario you could write this text in emacs (running in console mode):

(echo Does it work: \
  1. Select this text (both lines) with your mouse.
  2. Paste it to a terminal, and press

If it writes:

Does it work: true

Then it works as intended (copy-paste worked), you don't have my issue (why ?). But, on my computer I see:

Does it work:

And the "true" is missing : it fails as currently described in this issue.

Any suggestion ?

  • 1
    The experiment you describe gives me Does it work: true. Mac OS X 10.8.5, default emacs (22.1.1) without a single customization, iTerm2 2.0, bash 4.3.30. – romainl Oct 21 '14 at 12:21
  • @romaini ok, thanks I didn't think of customization. That was it. – vaab Oct 22 '14 at 5:18

When in console mode, syntax highlighting can get in the way and generate whole lines of "spaces" being copied within your selected code.

Checking this is the culprit

To check if this is what is plaguing you:

  • disable syntax highlighting temporarily with M-x global-font-lock-mode.
  • Then try to copy-paste and see if you can still reproduce the issue.
  • Once confirmed/infirmed, you can set syntax highlighting back with the same command.

If disabling syntax highlighting fixed your copy/paste issue, you might want the read the following to fix this definitively.

Why is that happening ?

What triggers the issue is that you have set a background color to some fonts (often on the default font). As a result, emacs is filling the background with empty chars so it can "paint" the screen as you wanted, and any copy-paste action will contains these spurious white spaces.

How to fix that ?

You should check your face customizations (for default font you could use M-x customize-face <RET> default <RET>) and if you have a background-color different from unspecified-bg then this is the culprit. unspecified-bg is some sort of transparent background color, and it's actually the default background color of emacs if you didn't customize it.

We can force the background to use unspecified-bg upon emacs start by adding this in you ~/.emacs, after any auto-generated custom-set-faces block:

(unless window-system
   '(default ((t (:background "unspecified-bg"))))))

Then either restart your emacs, or M-x eval-region on this block to check the result.

As a side note, you will also get back any fancy terminal's background trick in your emacs (I'm thinking of transparency or background images...).

NOTE: even with this, you could have some bad surprise with ghost white-spaces being captured in some special text, that would get a poorly highlighted font. In these cases, you might consider using the first trick.

More explanation of why this is happening

Terminals have a background color of their own (some terminal can even allow to display an image as background or to even be transparent). So for the console, there is like a nothing color (see it like an alpha channel), and this is the default color for console.

Console application can change both the color of the font and the background through ANSI escape sequences.

If you ask emacs to change the background color, it'll have to artificially paint the screen with white-spaces characters having their own background color set to whatever you chose.

When selecting, you often use the terminal copy-pasting functionality, that is totally unaware of the console application you are using. It does it job by copy-pasting whatever characters are on the screen, and will thus copy the white-spaces.

Note that you can have setup that will allow your console application to actually receive the mouses input and manage the selection and copy-paste. But it is not that common and the shell, which is the most common app that is active in your terminal do not support the mouse.

| improve this answer | |
  • 1
    Just ran into this myself, great answer, thanks. I don't use custom-set-faces though so I converted your answer to (unless window-system (set-face-attribute 'default nil :background "unspecified-bg")) and it worked for me. Although I find comment lines get the same space-filling behavior, but that's less horrible than all lines, at least. – robru Dec 27 '14 at 3:35
  • 1
    That fix (M-x customize-face <RET> default <RET> --> background-color: unspecified-bg) also fixed a slightly different issue that I was having in Aquamacs.app (MacOSX): When yanking lines, a single extra space was added at the very end of the yanked text -- so if I yanked 2 lines at the start of a file, the new line 3 would have a spurious space at the start. – DouglasDD Jul 10 '16 at 19:03
  • Disabling syntax highlighting temporarily worked, but modifying .emacs as specified did not (perhaps because I am running emacs within a tmux session?). – abeboparebop Aug 23 '18 at 10:16

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.