Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When I do an Emacs-copy or -cut in a text file with unix line endings (0x0a), and then look at the pasteboard in Terminal, the newlines have been replaced with lone carriage-returns.

The file (created with Emacs) has newline line-endings:

$ hexdump -C quick.txt
00000000  74 68 65 20 71 75 69 63  6b 0a 62 72 6f 77 6e 20  |the quick.brown |
00000010  66 6f 78 0a                                       |fox.|

Copying the file (in Terminal) to the paste buffer, then displaying the paste buffer, we still see the newlines:

$ pbcopy <quick.txt ; pbpaste | hexdump -C
00000000  74 68 65 20 71 75 69 63  6b 0a 62 72 6f 77 6e 20  |the quick.brown |
00000010  66 6f 78 0a                                       |fox.|

After opening the file with Emacs (windowed), selecting the text and copying with Cmd-W (bound to kill-ring-save), then displaying the paste buffer in Terminal, I get:

$ pbpaste | hexdump -C
00000000  74 68 65 20 71 75 69 63  6b 0d 62 72 6f 77 6e 20  |the quick.brown |
00000010  66 6f 78 0d                                       |fox.|

The newlines are now carriage-returns.

Why are they being translated, and how can I prevent it?

  • OS-X 10.6.7
  • Emacs 22.3.1 in a GUI window
  • Hiding .emacs.el has no effect on the translation (my customizations do go away).
share|improve this question
up vote 0 down vote accepted

I found a thread elsewhere about this "bug", including a fix ("bug" in quotes because it looks like a design decision by the Emacs developers, just one that doesn't work for me).

Seiji Zenitani opened the thread and posted a solution someone sent him (he doesn't say who), which I'll post below in case that thread goes away. The comments are mine; the code is as he posted it.

The gist of it is that there is a deliberate (apparently) translation from unix-mode to Mac-mode line endings when copying an Emacs-cut or -copy out to the OS-X pasteboard (\n -> \r, just exactly what I was seeing). Arguably, the pasteboard is used most often to paste into Mac applications so translating to Mac-mode on the pasteboard would make sense. Equally arguable is that Emacs users are likely to be working in the underlying Unix, so copying out the strings in unix mode makes sense, and that is the solution I chose. It helps that most Mac applications seem to accept Unix-mode strings.

The fix:

;; Bug fix for: "After Emacs copy, OS-X paste buffer gets CRs where LFs used to be", 
;; by redefining .../term/mac-win.el/mac-string-to-utxt.
;; Line 7 changes coding system to unix (was mac)
;; Lines 23,24   delete "-mac" from "utf-16be-mac" and "utf-16le-mac" and appear
;; to apply to Japanese encodings.
;; See:

(defun mac-string-to-utxt (string &optional coding-system)
 (or coding-system (setq coding-system mac-system-coding-system))
 (let (data encoding)
   (when (and (fboundp 'mac-code-convert-string)
              (memq (coding-system-base coding-system)
                    (find-coding-systems-string string)))
     (setq coding-system
           (coding-system-change-eol-conversion coding-system 'unix))
     (let ((str string))
       (when (and (eq system-type 'darwin)
                  (eq coding-system 'japanese-shift-jis-mac))
         (setq encoding mac-text-encoding-mac-japanese-basic-variant)
         (setq str (subst-char-in-string ?\\ ?\x80 str))
         (subst-char-in-string ?\\ ?\x5c str t)
         ;; ASCII-only?
         (if (string-match "\\`[\x00-\x7f]*\\'" str)
             (setq str nil)))
       (and str
            (setq data (mac-code-convert-string
                        (encode-coding-string str coding-system)
                        (or encoding coding-system) nil)))))
   (or data (encode-coding-string string (if (eq (byteorder) ?B)
share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .