From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup 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> <87lhp5m99w.fsf@fencepost.gnu.org> <87h9ztm5oa.fsf@fencepost.gnu.org> <87d2ahm3nw.fsf@fencepost.gnu.org> <871tqneyvl.fsf@netris.org> <87d2a54t1m.fsf@yeeloong.lan> <83lhotme1e.fsf@gnu.org> <871tql17uw.fsf@yeeloong.lan> <838uktm9gw.fsf@gnu.org> <87h9zgarvp.fsf@fencepost.gnu.org> <83y4srjaot.fsf@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 Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 09 09:52:44 2014 Return-path: 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 ) 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 ) 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 ) 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 ) 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 ) 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 ) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: Eli Zaretskii 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