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: Wed, 08 Oct 2014 09:37:49 +0200 Message-ID: <874mvf810y.fsf@fencepost.gnu.org> References: <54193A70.9020901@member.fsf.org> <871tqneyvl.fsf@netris.org> <87d2a54t1m.fsf@yeeloong.lan> <83lhotme1e.fsf@gnu.org> <871tql17uw.fsf@yeeloong.lan> <838uktm9gw.fsf@gnu.org> <87ppe5rt5l.fsf@uwakimon.sk.tsukuba.ac.jp> <87d2a4arju.fsf@fencepost.gnu.org> <878ukrc2sr.fsf@fencepost.gnu.org> <87vbnvamut.fsf@fencepost.gnu.org> <87mw97alvn.fsf@fencepost.gnu.org> <87iojvakl9.fsf@fencepost.gnu.org> <83wq8bjafs.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1412773732 26462 80.91.229.3 (8 Oct 2014 13:08:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 8 Oct 2014 13:08:52 +0000 (UTC) Cc: schwab@suse.de, rms@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 08 15:08:45 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 1Xbqyy-0003zK-JH for ged-emacs-devel@m.gmane.org; Wed, 08 Oct 2014 15:08:44 +0200 Original-Received: from localhost ([::1]:36108 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xbqyy-00083G-0U for ged-emacs-devel@m.gmane.org; Wed, 08 Oct 2014 09:08:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51554) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xbqyu-000837-5e for emacs-devel@gnu.org; Wed, 08 Oct 2014 09:08:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xbqyp-0007H7-1H for emacs-devel@gnu.org; Wed, 08 Oct 2014 09:08:39 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39765) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xbqyo-0007H3-VJ for emacs-devel@gnu.org; Wed, 08 Oct 2014 09:08:34 -0400 Original-Received: from localhost ([127.0.0.1]:46919 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbqyZ-0002lZ-ID; Wed, 08 Oct 2014 09:08:19 -0400 Original-Received: by lola (Postfix, from userid 1000) id 98724E060A; Wed, 8 Oct 2014 09:37:49 +0200 (CEST) In-Reply-To: <83wq8bjafs.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 08 Oct 2014 10:19:03 +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:175122 Archived-At: Eli Zaretskii writes: >> Date: Tue, 07 Oct 2014 20:47:46 -0400 >> From: Richard Stallman >> Cc: schwab@suse.de, emacs-devel@gnu.org >> >> We can set the defaults for those non-frile interfaces so as to reject >> invalid UTF-8 sequences. Then a program could specify to override the >> default and allow them. > > That has been tried (not with UTF-8, but I don't think this matters), > and failed miserably. The experience taught us that Emacs users > definitely don't want Emacs to do _anything_ about the unmodified > parts of text, except copy it verbatim. Even the question we ask at > buffer-save time is sometimes reported as an annoyance. As one data point, PostScript and PDF files generally constitute of plain readable text (I seem to remember latin-1 with an option to use some BOM in strings for getting UTF16 locally but I may be mistaken) but with inserted binary objects. At least with PostScript, the file is linear and one can edit in changes if one wants to. Obviously, any unintentional changes in the binary sections are going to stop the result from working. This is definitely a case where you want to have better editing capabilities than a hexdump would give you (as you cannot insert or delete strings comfortably in a hexdump), but you still want the binary portions to remain undisturbed as a block. -- David Kastrup