emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs Lisp's future


From: David Kastrup
Subject: Re: Emacs Lisp's future
Date: Wed, 08 Oct 2014 05:03:00 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

Mark H Weaver <address@hidden> writes:

> David Kastrup <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]