当我在带有 unix 行尾(0x0a)的文本文件中执行 Emacs-copy 或 -cut,然后查看终端中的剪贴板时,换行符已被单独的回车符取代。
该文件(使用 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)进行复制,然后在终端中显示粘贴缓冲区,我得到:
$ 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
- GUI 窗口中的 Emacs 22.3.1
- 隐藏 .emacs.el 对翻译没有影响(我的自定义做离开)。
答案1
我发现一个线程其他地方也提到了此“错误”,包括一个修复程序(“错误”用引号引起来,因为它看起来像是 Emacs 开发人员的设计决定,只是对我来说不起作用)。
Seiji Zenitani 开了这个帖子,并贴出了别人发给他的解决方案(他没有说是谁发的),如果这个帖子消失了,我会在下面贴出来。评论是我的;代码和他贴的一样。
其要点是,在将 Emacs-cut 或 -copy 复制到 OS-X 粘贴板时,会故意(显然)将行尾从 unix 模式转换为 Mac 模式(\n -> \r,正如我所看到的)。可以说,粘贴板最常用于粘贴到 Mac 应用程序中,因此在粘贴板上转换为 Mac 模式是有意义的。同样有争议的是,Emacs 用户可能在底层 Unix 中工作,因此以 unix 模式复制字符串是有意义的,这就是我选择的解决方案。大多数 Mac 应用程序似乎都接受 Unix 模式字符串,这很有帮助。
修复:
;; 错误修复:“Emacs 复制后,OS-X 粘贴缓冲区在 LF 所在的位置获取 CR”, ;; 通过重新定义.../term/mac-win.el/mac-string-to-utxt。 ;; 第 7 行将编码系统更改为 unix(原为 mac) ;; 第 23、24 行从“utf-16be-mac”和“utf-16le-mac”中删除“-mac”,并出现 ;; 适用于日语编码。 ;; 参见:http://old.nabble.com/Fwd%3A-Line-endings-bug-to10657191.html#a10730618 (defun mac-string-to-utxt(字符串和可选编码系统) (或编码系统(setq 编码系统 mac-system-coding-system)) (让(数据编码) (当(和(fboundp'mac-code-convert-string) (memq(编码系统基础编码系统) (find-coding-systems-string 字符串))) (setq 编码系统 (编码系统更改 eol 转换编码系统 'unix)) (让((str字符串)) (当(和(eq 系统类型'darwin) (eq 编码系统'japanese-shift-jis-mac)) (setq 编码 mac-text-encoding-mac-japanese-basic-variant) (setq str(subst-char-in-string?\\?\x80 str)) (subst-char-in-string?\\?\x5c str t) ;; 仅限 ASCII? (如果(字符串匹配“\\`[\x00-\x7f]*\\'” str) (setq str nil))) (和 str (setq 数据(mac-code-convert-string (编码字符串 str 编码系统) (或编码编码系统)无))))) (或数据(编码字符串字符串(if(eq(字节顺序)?B) 'utf-16be 'utf-16le)))))