[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs Lisp's future
From: |
David Kastrup |
Subject: |
Re: Emacs Lisp's future |
Date: |
Tue, 07 Oct 2014 18:52:18 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) |
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.
> But Emacs will still complain and ask if you try to save such a
> buffer.
(let ((coding-system-for-write 'utf-8-unix))
(with-temp-file "/tmp/bozo"
(insert(encode-coding-string (string (decode-char 'eight-bit 128))
'utf-8))))
od /tmp/bozo
0000000 000200
0000001
What you mean is that Emacs is asked to _select_ or to _verify_ a coding
system (as is customary for interactive editing of a file) it will do so
and get back to the user when necessary.
But that is _quite_ different from Emacs being _incapable_ of encoding
raw bytes to a file or a stream of a specified encoding. It means that
when you are using an _application_ that is expected to deliver only
decodable characters, then the _application_ will _ask_ before going
ahead.
But the _engine_ is perfectly capable of going through here. Once you
confuse engine and application and state "Emacs should not be able to
encode characters from the eight-bit set" rather than "the normal file
saving operation defaulting to using buffer-file-coding-system for
coding-system-for-write after verifying its suitability should ask
before picking a value of coding-system-for-write that cause a file to
be written that is not representable without raw bytes" you are
proposing to cripple Emacs.
Or GUILE.
--
David Kastrup
- Re: Emacs Lisp's future, (continued)
- Re: Emacs Lisp's future, Stephen J. Turnbull, 2014/10/06
- 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 <=
- Re: Emacs Lisp's future, Andreas Schwab, 2014/10/07
- 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