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: Tue, 07 Oct 2014 02:04:07 +0900 Message-ID: <87r3ylruyg.fsf@uwakimon.sk.tsukuba.ac.jp> References: <54193A70.9020901@member.fsf.org> <87k34qo4c1.fsf@fencepost.gnu.org> <54257C22.2000806@yandex.ru> <83iokato6x.fsf@gnu.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> <87d2a54t1m.fsf@yeeloong.lan> <83lhotme1e.fsf@gnu.org> <87fvf1dxha.fsf@fencepost.gnu.org> <83d2a5maib.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1412615118 13398 80.91.229.3 (6 Oct 2014 17:05:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 6 Oct 2014 17:05:18 +0000 (UTC) Cc: David Kastrup , rms@gnu.org, mhw@netris.org, dmantipov@yandex.ru, emacs-devel@gnu.org, handa@gnu.org, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 06 19:05:10 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 1XbBid-0004Pd-2E for ged-emacs-devel@m.gmane.org; Mon, 06 Oct 2014 19:05:07 +0200 Original-Received: from localhost ([::1]:53136 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbBic-0005w8-EH for ged-emacs-devel@m.gmane.org; Mon, 06 Oct 2014 13:05:06 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57451) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbBiS-0005sL-UF for emacs-devel@gnu.org; Mon, 06 Oct 2014 13:05:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XbBiN-0002qJ-1C for emacs-devel@gnu.org; Mon, 06 Oct 2014 13:04:56 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:58802) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbBi8-0002cX-GQ; Mon, 06 Oct 2014 13:04:36 -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 DF9261C391D; Tue, 7 Oct 2014 02:04:07 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id CCDD81A2888; Tue, 7 Oct 2014 02:04:07 +0900 (JST) In-Reply-To: <83d2a5maib.fsf@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:175025 Archived-At: Eli Zaretskii writes: > > From: David Kastrup > Indeed. But that's what is expected from an editor: not to change the > stuff the user didn't touch. If the user thinks of the "stuff" as characters, they will be unhappy if the editor displays raw bytes for something that could be decoded, and they will prefer standards conforming output, if only in those instances where non-conformant output results in an explosion in a later processor. Of course you are quite right that there are many cases where the user would be happiest if the editor didn't touch byte sequence that the user didn't explicitly tell it to touch. My point is that neither approach is always right. > > The solution obviously is to use a coding scheme for recoding that > > does _not_ reproduce unencodable bytes. > > An editor such as Emacs cannot do that, I think. It should do so as an option, with the alternative being to ask for confirmation (this would be automatically satisfied if input and output rawbytes handlers were separate) if nonconforming output would be produced. Emacs of *all* editors should not produce non-conforming output silently (unless explicitly silenced), even if it got non-conforming input.