Re: Emacs Lisp's future

[David Kastrup <dak@gnu.org>]

Eli Zaretskii <eliz@gnu.org> 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