Após a cópia do Emacs, o buffer de colar do OS-X obtém CRs em vez de LFs

1

Quando eu faço um Emacs-copy ou -cut em um arquivo de texto com terminações de linha unix (0x0a) e, em seguida, examino a área de trabalho no Terminal, as novas linhas foram substituídas por retornos de carro solitário.

O arquivo (criado com o Emacs) tem finais de linha de nova linha:

$ 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

Copiando o arquivo (no Terminal) para o buffer de colar e exibindo o buffer de colagem, ainda vemos as novas linhas:

$ 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

Após abrir o arquivo com o Emacs (windowed), selecionando o texto e copiando com Cmd-W (ligado ao kill-ring-save), então exibindo o buffer de colar no Terminal, recebo:

$ 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

As novas linhas agora são retornos de carro.

Por que eles estão sendo traduzidos e como posso preveni-lo?

  • OS-X 10.6.7
  • Emacs 22.3.1 em uma janela da GUI
  • Ocultar .emacs.el não afeta a tradução (minhas customizações do desaparecem)
por JRobert 06.06.2011 / 19:53

1 resposta

0

Eu encontrei um tópico em outro lugar sobre esse "bug", incluindo uma correção ("bug" entre aspas porque parece uma decisão de design dos desenvolvedores do Emacs, apenas uma que não funciona para mim).

Seiji Zenitani abriu o tópico e postou uma solução que alguém lhe enviou (ele não diz quem), que postarei abaixo caso o tópico desapareça. Os comentários são meus; o código é como ele postou.

A essência disso é que há uma tradução (aparentemente) deliberada do modo unix para as terminações de linha no modo Mac ao copiar um Emacs-cut ou -copy para o pasteboard OS-X (\ n - > \ r, exatamente o que eu estava vendo). Indiscutivelmente, o papelão é usado com mais freqüência para colar em aplicativos do Mac, portanto, traduzir para o modo Mac na área de trabalho faria sentido. Igualmente discutível é que os usuários do Emacs provavelmente estarão trabalhando no Unix subjacente, então copiar as strings no modo unix faz sentido, e essa é a solução que escolhi. Isso ajuda que a maioria dos aplicativos Mac parecem aceitar strings no modo Unix.

A correção:

;; 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)))))
    
por 08.06.2011 / 00:41

Tags