From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Wed, 08 Oct 2014 03:15:26 +0900 Message-ID: <874mvfsq4h.fsf@uwakimon.sk.tsukuba.ac.jp> References: <54193A70.9020901@member.fsf.org> <87wq8pwjen.fsf@uwakimon.sk.tsukuba.ac.jp> <837g0ptnlj.fsf@gnu.org> <87r3yxwdr6.fsf@uwakimon.sk.tsukuba.ac.jp> <87tx3tmi3t.fsf@fencepost.gnu.org> <834mvttgsf.fsf@gnu.org> <87lhp5m99w.fsf@fencepost.gnu.org> <87h9ztm5oa.fsf@fencepost.gnu.org> <87d2ahm3nw.fsf@fencepost.gnu.org> <871tqneyvl.fsf@netris.org> <871tqlubqe.fsf@uwakimon.sk.tsukuba.ac.jp> <87lhosso3m.fsf@uwakimon.sk.tsukuba.ac.jp> <878ukrsx62.fsf@uwakimon.sk.tsukuba.ac.jp> <87zjd7amy6.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1412707969 6994 80.91.229.3 (7 Oct 2014 18:52:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 7 Oct 2014 18:52:49 +0000 (UTC) Cc: rms@gnu.org, mhw@netris.org, dmantipov@yandex.ru, emacs-devel@gnu.org, handa@gnu.org, monnier@iro.umontreal.ca, eliz@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 07 20:16:42 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 1XbZJS-0006Qz-7e for ged-emacs-devel@m.gmane.org; Tue, 07 Oct 2014 20:16:42 +0200 Original-Received: from localhost ([::1]:60300 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbZJR-0003MC-PL for ged-emacs-devel@m.gmane.org; Tue, 07 Oct 2014 14:16:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41937) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbZJ7-0003M0-Qw for emacs-devel@gnu.org; Tue, 07 Oct 2014 14:16:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XbZJ0-0006CR-4h for emacs-devel@gnu.org; Tue, 07 Oct 2014 14:16:21 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:41478) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbZIk-0005yU-96; Tue, 07 Oct 2014 14:15:58 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id CCAD51C3926; Wed, 8 Oct 2014 03:15:26 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id BE39A1A2888; Wed, 8 Oct 2014 03:15:26 +0900 (JST) In-Reply-To: <87zjd7amy6.fsf@fencepost.gnu.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.158.97.161 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:175094 David Kastrup writes: > I repeat: that is to be the choice of the application rather than > the engine. Which is what *I* said. But the engine *should* have a default for convenience of at least some use cases. What Mark (AFAICS) and I want is to default to not emitting broken Unicode. If the application chooses to do so, it should do so explicitly. > "We know better than the application writer what he wants" is > rarely going to work to the satisfaction of all. Again, I've said that in this thread already. Finally, note that there's nothing nonconformant about rawbytes in the internal representation per se. The Unicode standard is for *interchange* and says nothing about Emacs buffers. If TeX is produces invalid UTF-8 and AUCTeX accepts that and converts invalid UTF-8 to rawbytes, that's not a problem -- everybody knows what is going on -- and conformance is a non-issue, since it's all internal. (I don't claim Mark agrees with this paragraph. And he probably doesn't for the applications he envisions, because they are modular (where Emacs is monolithic), and therefore strings in internal representation are passed across module boundaries.) But Emacs should not save that buffer to a file or send its contents to a network stream, without either explicit permission from the user, or explicit configuration of the output stream by the application. Autosaves are another thorny problem. I suppose they will be handled by declaring them conformant only to Emacs' needs.