[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: |
Thu, 09 Oct 2014 09:52:31 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) |
Eli Zaretskii <address@hidden> writes:
>> I don't think we are talking about the same thing. I am talking
>> about Lisp functions to do conversions on text that does NOT come
>> from files.
>
> ... Emacs treats all of these cases the same.
Well, on a fine-grained level. We have something like
Coding system for saving this buffer:
U -- utf-8-emacs-unix (alias: emacs-internal)
Default coding system (for new files):
U -- utf-8-unix (alias: mule-utf-8-unix)
Coding system for keyboard input:
U -- utf-8-unix (alias: mule-utf-8-unix)
Coding system for terminal output:
U -- utf-8-unix (alias: mule-utf-8-unix)
Coding system for inter-client cut and paste:
nil
Defaults for subprocess I/O:
decoding: U -- utf-8-unix (alias: mule-utf-8-unix)
encoding: U -- utf-8-unix (alias: mule-utf-8-unix)
Priority order for recognizing coding systems when reading files:
1. utf-8 (alias: mule-utf-8)
2. iso-2022-7bit
3. iso-latin-1 (alias: iso-8859-1 latin-1)
4. iso-2022-7bit-lock (alias: iso-2022-int-1)
5. iso-2022-8bit-ss2
6. emacs-mule
[...]
20. undecided
Other coding systems cannot be distinguished automatically
from these, and therefore cannot be recognized automatically
with the present coding system priorities.
Particular coding systems specified for certain file names:
OPERATION TARGET PATTERN CODING SYSTEM(s)
--------- -------------- ----------------
File I/O "\\.dz\\'" (no-conversion . no-conversion)
"\\.txz\\'" (no-conversion . no-conversion)
[...]
Process I/O nothing specified
Network I/O nothing specified
> For text we are going to send to a process or network stream, we ask
> the above-mentioned question at the time we encode the internal
> representation into the external byte stream we are about to send.
It depends on how you specify the coding system. When setting the
principally responsible variable for an operation, you get no questions
asked. When setting some user-level specifiable preference, Emacs will
prompt for alternatives when accepting that preference unasked would
likely have user-level consequences that might or might not be
acceptable.
> E.g., you can see that in action in sending mail if you insert some
> raw bytes into a mail message in a *mail* buffer, and then try sending
> it. There's no file involved here, at least not as far as Emacs is
> concerned, and yet you will see the same prompt asking you to select a
> proper encoding.
Well, in the case of mail that makes sense since otherwise the content
will not likely survive the designated channel. It is perfectly
reasonable in my book to not silently go through with operations leading
to a an expected loss of information.
I still don't want the autosave of mail to complain about bad
characters. It's important that an application can pick where to apply
its checks and balances itself.
--
David Kastrup
- Re: Emacs Lisp's future, (continued)
- Re: Emacs Lisp's future, Florian Weimer, 2014/10/11
- Re: Emacs Lisp's future, Eli Zaretskii, 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, Richard Stallman, 2014/10/08
- Re: Emacs Lisp's future, Eli Zaretskii, 2014/10/09
- Re: Emacs Lisp's future,
David Kastrup <=
- Re: Emacs Lisp's future, Eli Zaretskii, 2014/10/09
- Re: Emacs Lisp's future, David Kastrup, 2014/10/09
- Re: Emacs Lisp's future, Mark H Weaver, 2014/10/12
- Re: Emacs Lisp's future, David Kastrup, 2014/10/13
- Re: Emacs Lisp's future, Richard Stallman, 2014/10/10
- Re: Emacs Lisp's future, Eli Zaretskii, 2014/10/10
- Re: Emacs Lisp's future, Richard Stallman, 2014/10/10
- Re: Emacs Lisp's future, Eli Zaretskii, 2014/10/11
- Re: Emacs Lisp's future, Mark H Weaver, 2014/10/11
- Re: Emacs Lisp's future, Stephen J. Turnbull, 2014/10/11