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 05:03:00 +0200 Message-ID: <87oatn8dqz.fsf@fencepost.gnu.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> <87mw97rjwm.fsf@yeeloong.lan> <8761fvn8io.fsf@yeeloong.lan> <87egujahw6.fsf@fencepost.gnu.org> <87wq8bd8w2.fsf@netris.org> <87y4sr909s.fsf@fencepost.gnu.org> <87ppe3lbkr.fsf@yeeloong.lan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1412773777 27105 80.91.229.3 (8 Oct 2014 13:09:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 8 Oct 2014 13:09:37 +0000 (UTC) Cc: Richard Stallman , Andreas Schwab , dmantipov@yandex.ru, emacs-devel@gnu.org, handa@gnu.org, monnier@iro.umontreal.ca, Eli Zaretskii , stephen@xemacs.org To: Mark H Weaver Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 08 15:09:29 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 1Xbqzh-0004JL-1W for ged-emacs-devel@m.gmane.org; Wed, 08 Oct 2014 15:09:29 +0200 Original-Received: from localhost ([::1]:36114 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xbqzg-0008Rq-Io for ged-emacs-devel@m.gmane.org; Wed, 08 Oct 2014 09:09:28 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51812) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xbqz9-0008Ne-3g for emacs-devel@gnu.org; Wed, 08 Oct 2014 09:08:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xbqz8-0007Vd-9Y for emacs-devel@gnu.org; Wed, 08 Oct 2014 09:08:55 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39815) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xbqz8-0007VY-7P for emacs-devel@gnu.org; Wed, 08 Oct 2014 09:08:54 -0400 Original-Received: from localhost ([127.0.0.1]:46921 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbqyZ-0002lc-Ij; Wed, 08 Oct 2014 09:08:19 -0400 Original-Received: by lola (Postfix, from userid 1000) id EDBE0DF341; Wed, 8 Oct 2014 05:03:00 +0200 (CEST) In-Reply-To: <87ppe3lbkr.fsf@yeeloong.lan> (Mark H. Weaver's message of "Tue, 07 Oct 2014 19:11:32 -0400") 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:175124 Archived-At: Mark H Weaver writes: > David Kastrup writes: >> You cannot successfully cater for clueless application programmers. > > It is not "clueless" to expect a UTF-8 encoder to produce valid UTF-8. We are not talking about "producing" but "reproducing" here. It is clueless to expect manure to magically turn into roses without instructions. If you need sanitized output, you need to sanitize your input at some point of time. If that point of time is not under your control, that will cause worse problems than you started with. You get denial-of-service attack vectors when raising exceptions, you get quoting attack vectors when silently removing or replacing characters. It is much harder to deal with those behaviors reliably than it is to deal with faithful reproduction, letting you put the cleanup strategies at the place in processing where they belong. Like, before any quoting, and after any unquoting. And, of course, having the full power of GUILE's string and regexp processing for dealing programmatically with that cleanup. There is no "we don't have to deal with that input anyway" excuse for a programming platform. Emacs learnt its MULE lessons the hard way. And these days, it does not let its application programmers down. And since the programmers were free to put any safety nets at any place _they_ want without risking gratuitous breakage, Emacs will inform the user of possible coding problems exactly where the application programmers considered warnings appropriate, and with exactly the fallbacks and options that the programmers considered appropriate for that particular use case. -- David Kastrup