Re: Emacs Lisp's future

["Stephen J. Turnbull" <stephen@xemacs.org>]

Richard Stallman writes:

 > The defaults for the standard Guile primitives could be strict,
 > and the defaults for some Emacs Lisp functions could be flexible.

Which is precisely what I proposed from the beginning[1], and as I
understand his posts, it is what Mark has had in mind throughout as
well.

Speaking *only* for myself, I would *prefer* defaults for text coding
set by Emacs to be strict, and I believe that is both in the average
user's interest and not too inconvenient *in today's environment*.[2]
But it should be easy for applications and modes to say to Emacs "do
what you would have done in Emacs 24" and "do what you would have done
in Emacs 24 *except* apply a strict(er) error handling on invalid
encoding".

Experience may show that my preferred default is too strict for Emacs,
even today, but I believe it is the place to start.

FWIW IMHO YMMV


Footnotes: 
[1]  Although my expression of that proposal seems to have been
unintelligible.  Sorry!

[2]  tl;dr

UTF-8 is rapidly becoming the preferred encoding for many natural
languages, although China encourages GB18030 by law and Japan and
Russia both maintain their historical Babel of encodings.  Protocols
are both becoming stricter about validation, and using the sensible
default of UTF-8.  Internet protocols, where security is a very
important aspect, are gradually shifting from insisting on ASCII to
defaulting to UTF-8 (although often in some kind of "ASCII-armored"
encoding such as BASE64 or punycode).

So in general, with a few application-specific exceptions (hello,
AUCTeX), both users and applications should encounter far fewer
instances of broken encoding than in the era when the experiments Eli
and David refer to were conducted.  This is somewhat supported by the
fact that at least one major dynamic language (Python) doesn't even
provide an encoding detection function in its standard library.  The
typical range of use cases is different, granted, but editing
applications (the IDLE IDE and the IPython "notebook" facility) don't
seem to have issues with defaulting to "strict".