[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Line endings bug
From: |
YAMAMOTO Mitsuharu |
Subject: |
Re: Line endings bug |
Date: |
Tue, 22 May 2007 12:29:29 +0900 |
User-agent: |
Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shijō) APEL/10.6 Emacs/22.0.990 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) |
>>>>> On Mon, 21 May 2007 22:34:30 -0400, Seiji Zenitani <address@hidden> said:
>> I'm not quite sure what bug is fixed by that change. What was OP's
>> concrete problem?
>>
> I'm sorry but I lost contact with him.
Hmm, how can we incorporate that code in the case that it is correct?
>>> The default eol character seems to be 'unix and I hear OS X's
>>> internal code is utf-16 + LF (unix). Could you please examine it?
>>
>> At least, Safari and Apple Mail use CR when they put multi-line
>> data to the clipboard.
> How to confirm this?
(x-get-selection-internal 'CLIPBOARD 'public.utf16-plain-text)
This gives us raw byte data without any conversions.
> When I copy text from the Safari/Mail.app and then type the
> following command, the text file "sample.txt" has LF, not CR.
> $ pbpaste > sample.txt
> $ hexdump sample.txt
I can see the difference in the results of pbpaste between Safari and
Emacs. As both Safari and pbpaste are Cocoa apps, some hidden
information might be used to determine the actual EOL type. But I
think that the current behavior of Emacs is correct as a Carbon app.
YAMAMOTO Mitsuharu
address@hidden