После копирования Emacs буфер вставки OS-X получает CR вместо LF

Question

Когда я делаю Emacs-копию или -cut в текстовом файле с окончанием строки Unix (0x0a), а затем смотрю на монтажную панель в Терминале, новые строки заменяются одиночными возвратами каретки.

Файл (созданный с помощью Emacs) имеет новые строки:

$ 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.|
00000014

Скопировав файл (в Терминале) в буфер вставки, затем отобразив буфер вставки, мы все еще видим новые строки:

$ 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.|
00000014

После открытия файла в Emacs (в окне), выбора текста и копирования с помощью Cmd-W (привязанного к kill-ring-save), а затем отображения буфера вставки в Terminal, я получаю:

$ 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.|
00000014

Новые строки - теперь возврат каретки.

Почему они переводятся, и как я могу предотвратить это?

• OS-X 10.6.7
• Emacs 22.3.1 в окне графического интерфейса
• Скрытие .emacs.el не оказывает никакого влияния на перевод (мои настройки действительно уходят).

Answer 1

Я нашел нить в другом месте об этом "ошибка", в том числе исправление ("ошибка" в кавычках , потому что это выглядит как проектное решение со стороны разработчиков Emacs, только один , который не работает для меня).

Сейджи Зенитани открыл ветку и опубликовал решение, которое ему отправил кто-то (он не говорит, кто), которое я опубликую ниже на случай, если эта ветка исчезнет. Комментарии мои; код такой, как он опубликовал.

Суть его заключается в том, что при копировании Emacs-cut или -copy из монтажной области OS-X (\n -> \r, точно, существует точный (очевидно) перевод из окончаний строк в режиме Unix в режим Mac). что я видел). Можно утверждать, что монтажный картон чаще всего используется для вставки в приложения Mac, поэтому имеет смысл перевести его в режим Mac на монтажном картоне. Не менее спорным является то, что пользователи Emacs, вероятно, будут работать в базовом Unix, поэтому имеет смысл копировать строки в режиме Unix, и это решение я выбрал. Это помогает, что большинство приложений Mac, кажется, принимают строки в режиме Unix.

Исправление:

;; 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: http://old.nabble.com/Fwd%3A-Line-endings-bug-to10657191.html#a10730618

(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)
                                             'utf-16be
                                           'utf-16le)))))