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: Dynamic loading progress Date: Sun, 22 Nov 2015 21:59:43 +0100 Message-ID: <87ziy57nsw.fsf@fencepost.gnu.org> References: <8737w3qero.fsf@lifelogs.com> <831tbn9g9j.fsf@gnu.org> <878u5upw7o.fsf@lifelogs.com> <83ziya8xph.fsf@gnu.org> <83y4du80xo.fsf@gnu.org> <837fld6lps.fsf@gnu.org> <83si3z4s5n.fsf@gnu.org> <83mvu74nhm.fsf@gnu.org> <83d1v34hba.fsf@gnu.org> <83io4u2aze.fsf@gnu.org> <8337vx3kp6.fsf@gnu.org> <83y4dp24pq.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1448226021 20230 80.91.229.3 (22 Nov 2015 21:00:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 22 Nov 2015 21:00:21 +0000 (UTC) Cc: aurelien.aptel+emacs@gmail.com, Philipp Stephani , tzz@lifelogs.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 22 22:00:06 2015 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 1a0bjw-000840-6A for ged-emacs-devel@m.gmane.org; Sun, 22 Nov 2015 22:00:04 +0100 Original-Received: from localhost ([::1]:57482 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0bjw-0005mo-2n for ged-emacs-devel@m.gmane.org; Sun, 22 Nov 2015 16:00:04 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54745) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0bjh-0005mc-Aa for emacs-devel@gnu.org; Sun, 22 Nov 2015 15:59:50 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a0bjg-0002DF-9v for emacs-devel@gnu.org; Sun, 22 Nov 2015 15:59:49 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:49215) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0bjd-0002CP-7K; Sun, 22 Nov 2015 15:59:45 -0500 Original-Received: from localhost ([127.0.0.1]:34801 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.82) (envelope-from ) id 1a0bjc-0002HK-Er; Sun, 22 Nov 2015 15:59:44 -0500 Original-Received: by lola (Postfix, from userid 1000) id EEC94DF5F8; Sun, 22 Nov 2015 21:59:43 +0100 (CET) In-Reply-To: <83y4dp24pq.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 22 Nov 2015 21:50:57 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.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:195068 Archived-At: Eli Zaretskii writes: >> From: Philipp Stephani > >> > No matter what we expect or tolerate, we need to state that. >> >> No, we don't. When the callers violate the contract, they cannot >> expect to know in detail what will happen. If they want to know, they >> will have to read the source. >> >> So you want this to be unspecified or undefined behavior? That might be OK (we >> already have that in several places), but we still need to state what the >> contract is. > > You can call it "undefined behavior" if you want. Personally, I don't > think that's accurate: "undefined" means anything can happen, whereas > Emacs at least promises to output the original bytes unchanged, as > long as the text modifications didn't touch them. Uh, no? After converting from utf-8-unix to emacs-internal, Emacs' own processing will not affect originally bad sequences in utf-8-unix. However, that would require all string passing to include a decoding/encoding step so that the nominal encoding used by the module is utf-8-unix. I think in the interest of both roundtrip times as well as general usefulness of modules, it would be better if the default communication encoding with the module would indeed be emacs-internal. That way, modules can solve problems outside of Unicode proper. This is definitely not a no-brainer: choosing utf-8-unix as the communication encoding for modules would be an interface with less dependency on Emacs' coding internals but it would pin down UTF-8 as the only actual useful encoding modules could be made to deal with and would incur performance penalties. -- David Kastrup