From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Sun, 12 Oct 2014 23:04:06 -0400 Message-ID: <871tqcy8k9.fsf@netris.org> References: <54193A70.9020901@member.fsf.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> <8738ax7k8w.fsf@fencepost.gnu.org> <83k349iqjj.fsf@gnu.org> <87iojt61j4.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1413169487 26949 80.91.229.3 (13 Oct 2014 03:04:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 13 Oct 2014 03:04:47 +0000 (UTC) Cc: rms@gnu.org, dmantipov@yandex.ru, emacs-devel@gnu.org, handa@gnu.org, monnier@iro.umontreal.ca, Eli Zaretskii , stephen@xemacs.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 13 05:04:41 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 1XdVw8-0002HM-P1 for ged-emacs-devel@m.gmane.org; Mon, 13 Oct 2014 05:04:40 +0200 Original-Received: from localhost ([::1]:59931 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdVw8-0001d3-88 for ged-emacs-devel@m.gmane.org; Sun, 12 Oct 2014 23:04:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38634) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdVvs-0001ct-SH for emacs-devel@gnu.org; Sun, 12 Oct 2014 23:04:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XdVvo-0000ks-Gw for emacs-devel@gnu.org; Sun, 12 Oct 2014 23:04:24 -0400 Original-Received: from world.peace.net ([96.39.62.75]:38689) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdVvf-0000hw-JE; Sun, 12 Oct 2014 23:04:11 -0400 Original-Received: from c-24-62-95-23.hsd1.ma.comcast.net ([24.62.95.23] helo=jojen) by world.peace.net with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1XdVvX-00034Z-3f; Sun, 12 Oct 2014 23:04:03 -0400 In-Reply-To: <87iojt61j4.fsf@fencepost.gnu.org> (David Kastrup's message of "Thu, 09 Oct 2014 11:22:07 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.94 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 96.39.62.75 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:175297 Archived-At: David Kastrup writes: > Eli Zaretskii writes: > >>> From: David Kastrup >>> Cc: rms@gnu.org, mhw@netris.org, dmantipov@yandex.ru, >>> emacs-devel@gnu.org, handa@gnu.org, monnier@iro.umontreal.ca, >>> stephen@xemacs.org >>> Date: Thu, 09 Oct 2014 09:52:31 +0200 >>> >>> I still don't want the autosave of mail to complain about bad >>> characters. >> >> We write the auto-save files in the internal format, so it never >> complains. > > If you are not allowed or able to do that... At the current point of > time, the only round-trippable encoding for bytes that GUILE offers is > latin-1, and the only round-trippable encoding for characters is utf-8. "Not allowed"? Another strawman. I guess it's a waste of time for me to say, yet again, that we'll support the "raw bytes" encodings, because you'll just keep on pretending that we won't allow it. > The conceptual lack of separation between internal and external utf-8 > encoding leads to strangenesses like > > scheme@(guile-user)> (with-input-from-string "\ufeff!" read-char) > $8 = #\! > > Yes, this is a string->string operation losing a byte order mark in > spite of no indication that I would like to get encodings involved in > any manner. Byte Order Marks are an ugly corner of Unicode, and I spent a lot of effort to try to do the right thing here. What we do in Guile is described here: https://www.gnu.org/software/guile/manual/html_node/BOM-Handling.html I agree that we should inhibit BOM handling for string ports. > And when I can say "let's see where this kind of thinking will lead" and > find a hole to poke within a minute, BTW, your claim that you found this hole "within a minute" is a bald-faced lie and you know it. In , I stated my belief that our internal use of UTF-8 in string ports was not visible to the application as long as you didn't manually change the encoding for the string port or use seek/ftell. That was on Sept 24th. You spent a *lot* of time arguing with us in that bug report, and this is exactly the observation you could have used to bolster your argument, but you never found it until now. Mark