From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.org!not-for-mail
From: David Kastrup <dak@gnu.org>
Newsgroups: gmane.emacs.devel
Subject: Re: Emacs Lisp's future
Date: Thu, 09 Oct 2014 09:52:31 +0200
Message-ID: <8738ax7k8w.fsf@fencepost.gnu.org>
References: <54193A70.9020901@member.fsf.org>
	<jwvoau19n3n.fsf-monnier+emacs@gnu.org>
	<87lhp5m99w.fsf@fencepost.gnu.org>
	<jwviok99jki.fsf-monnier+emacs@gnu.org>
	<87h9ztm5oa.fsf@fencepost.gnu.org>
	<jwvd2ah9hve.fsf-monnier+emacs@gnu.org>
	<87d2ahm3nw.fsf@fencepost.gnu.org>
	<jwv1tqx9ea3.fsf-monnier+emacs@gnu.org>
	<E1XYNnY-0005Zo-Kz@fencepost.gnu.org> <871tqneyvl.fsf@netris.org>
	<E1XatgY-00062K-7y@fencepost.gnu.org> <87d2a54t1m.fsf@yeeloong.lan>
	<83lhotme1e.fsf@gnu.org> <871tql17uw.fsf@yeeloong.lan>
	<838uktm9gw.fsf@gnu.org> <E1XbVNk-0005OC-84@fencepost.gnu.org>
	<87h9zgarvp.fsf@fencepost.gnu.org>
	<E1XbfPE-0008Id-BH@fencepost.gnu.org> <83y4srjaot.fsf@gnu.org>
	<E1Xc2OY-0001qs-Rx@fencepost.gnu.org> <83r3yhiu8c.fsf@gnu.org>
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: text/plain
X-Trace: ger.gmane.org 1412841171 28685 80.91.229.3 (9 Oct 2014 07:52:51 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Thu, 9 Oct 2014 07:52:51 +0000 (UTC)
Cc: rms@gnu.org, mhw@netris.org, dmantipov@yandex.ru, emacs-devel@gnu.org,
	handa@gnu.org, monnier@iro.umontreal.ca, stephen@xemacs.org
To: Eli Zaretskii <eliz@gnu.org>
Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 09 09:52:44 2014
Return-path: <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>
Envelope-to: ged-emacs-devel@m.gmane.org
Original-Received: from lists.gnu.org ([208.118.235.17])
	by plane.gmane.org with esmtp (Exim 4.69)
	(envelope-from <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>)
	id 1Xc8Wh-00027T-Dp
	for ged-emacs-devel@m.gmane.org; Thu, 09 Oct 2014 09:52:43 +0200
Original-Received: from localhost ([::1]:40919 helo=lists.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>)
	id 1Xc8Wh-0005Dh-2m
	for ged-emacs-devel@m.gmane.org; Thu, 09 Oct 2014 03:52:43 -0400
Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57261)
	by lists.gnu.org with esmtp (Exim 4.71) (envelope-from <dak@gnu.org>)
	id 1Xc8We-0005DQ-1p
	for emacs-devel@gnu.org; Thu, 09 Oct 2014 03:52:41 -0400
Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <dak@gnu.org>) id 1Xc8Wc-00074q-Lu
	for emacs-devel@gnu.org; Thu, 09 Oct 2014 03:52:39 -0400
Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33286)
	by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <dak@gnu.org>)
	id 1Xc8Wc-00074m-JN
	for emacs-devel@gnu.org; Thu, 09 Oct 2014 03:52:38 -0400
Original-Received: from localhost ([127.0.0.1]:40461 helo=lola)
	by fencepost.gnu.org with esmtp (Exim 4.71)
	(envelope-from <dak@gnu.org>)
	id 1Xc8WV-0000lB-IR; Thu, 09 Oct 2014 03:52:31 -0400
Original-Received: by lola (Postfix, from userid 1000)
	id 0AEF3E0500; Thu,  9 Oct 2014 09:52:31 +0200 (CEST)
In-Reply-To: <83r3yhiu8c.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 09 Oct
	2014 10:21:23 +0300")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)
X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address
	(bad octet value).
X-Received-From: 2001:4830:134:3::e
X-BeenThere: emacs-devel@gnu.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: "Emacs development discussions." <emacs-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/emacs-devel>
List-Post: <mailto:emacs-devel@gnu.org>
List-Help: <mailto:emacs-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=subscribe>
Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org
Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org
Xref: news.gmane.org gmane.emacs.devel:175173
Archived-At: <http://permalink.gmane.org/gmane.emacs.devel/175173>

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