[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 19:38:30 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.94 (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:
>>>>>>
>>>>>>> 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.
>
> It would appear that you are forcing your logic. "No encoding can ..."
> does not mean that.
That's what Emacs told me, with the heuristics you are talking about.
Andreas.
--
Andreas Schwab, address@hidden
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
- Re: Emacs Lisp's future, (continued)
- Re: Emacs Lisp's future, Richard Stallman, 2014/10/07
- Re: Emacs Lisp's future, David Kastrup, 2014/10/07
- Re: Emacs Lisp's future, Andreas Schwab, 2014/10/07
- Re: Emacs Lisp's future, David Kastrup, 2014/10/07
- Re: Emacs Lisp's future, Andreas Schwab, 2014/10/07
- Re: Emacs Lisp's future, David Kastrup, 2014/10/07
- Re: Emacs Lisp's future, Andreas Schwab, 2014/10/07
- Re: Emacs Lisp's future, David Kastrup, 2014/10/07
- Re: Emacs Lisp's future, Andreas Schwab, 2014/10/07
- Re: Emacs Lisp's future, David Kastrup, 2014/10/07
- Re: Emacs Lisp's future,
Andreas Schwab <=
- Re: Emacs Lisp's future, Richard Stallman, 2014/10/07
- Re: Emacs Lisp's future, Eli Zaretskii, 2014/10/08
- Re: Emacs Lisp's future, David Kastrup, 2014/10/08
- Re: Emacs Lisp's future, Stefan Monnier, 2014/10/06
- Re: Emacs Lisp's future, Mark H Weaver, 2014/10/06
- Re: Emacs Lisp's future, Stefan Monnier, 2014/10/06
- Re: Emacs Lisp's future, Richard Stallman, 2014/10/07
- Re: Emacs Lisp's future, Richard Stallman, 2014/10/07
- Re: Emacs Lisp's future, David Kastrup, 2014/10/07
- Re: Emacs Lisp's future, Mark H Weaver, 2014/10/07