emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs Lisp's future


From: Andreas Schwab
Subject: Re: Emacs Lisp's future
Date: Tue, 07 Oct 2014 18:31:03 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

David Kastrup <address@hidden> writes:

> Andreas Schwab <address@hidden> writes:
>
>> David Kastrup <address@hidden> writes:
>>
>>> Andreas Schwab <address@hidden> writes:
>>>
>>>> David Kastrup <address@hidden> writes:
>>>>
>>>>> Andreas Schwab <address@hidden> writes:
>>>>>
>>>>>> David Kastrup <address@hidden> writes:
>>>>>>
>>>>>>> One problem with that is that quite often Emacs' choice of a coding
>>>>>>> system for a buffer is the result of heuristics rather than dependable
>>>>>>> information.  Not making a fuzz might often be simplest.
>>>>>>
>>>>>> If you try to save a buffer Emacs will check whether all characters are
>>>>>> encodable, and complain (and ask) if they aren't.
>>>>>
>>>>> Sure, but a raw byte is trivially encodable since it is no character.
>>>>
>>>> This is a contradiction.  It isn't a character, so it isn't encodable.
>>>
>>> The character representation of "raw byte" is trivially encodable since
>>> it represents a single byte in any encoding.
>>
>> No encoding (except raw-text) can encode characters from the eight-bit
>> charset.
>
> (encode-coding-string (string (decode-char 'eight-bit 128)) 'utf-8)
> => "\200"

That's what you get if you *force* the coding system.  But Emacs will
still complain and ask if you try to save such a buffer.

Andreas.

-- 
Andreas Schwab, SUSE Labs, address@hidden
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."



reply via email to

[Prev in Thread] Current Thread [Next in Thread]