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: Sat, 11 Oct 2014 09:18:35 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

Richard Stallman <address@hidden> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>     > They don't HAVE to be treated the same.  We are talking about changes,
>     > here.
>
>     They will be very deep and invasive changes, because currently the
>     encoding/decoding routines don't know the purpose of the stuff they
>     are producing.
>
> No, it's just a matter of setting some parameter to specify a particular
> decision in decoding or encoding behavior.
>
>     > But changes may not be needed.  All operations that do encoding or
>     > decoding allow explicit specification of the coding system.
>
>     Of course, they do.  But the issue at hand is precisely whether it is
>     the application's responsibility to explicitly specify conversions
>     that will be strict wrt invalid byte sequences, or should Emacs do
>     that by default.
>
> Yes.
>
> It will be easy to specify one or the other, so why not make the default
> be strict, except in the primitives that operate on files?

Because we had that already.  It made the users mad, it threw spanners
in the work of the programmers, and there is a large body of software
developed before then and since then that depends on Emacs working
rather than throwing a fit.

When we lost users in large droves to XEmacs at the time Emacs became
the loss leader for multibyte encodings by making MULE manadatory, a
significant number of those users who went were the ones not even using
non-ASCII locales, and they would purportedly not even have noticed a
difference with the files they were supposed to be working with.  But in
practice, files and communications don't pass the purity tests.

When you have a secretary working for you, you are not interested in the
secretary getting each grammatical error in a letter you got sent
circled in red.

When I read a mail from an issue ticketing system that has not
encoded/decoded some mail headers properly along with the rest, I still
want to be able to read what is there _before_ making decisions about
encodings.  Most of the time I don't want to make _any_ decision and
just go ahead with what I got.  And frankly: if Emacs refuses to show me
what it got before I make a decision, I have no _base_ for making a
decision in the first place.

-- 
David Kastrup



reply via email to

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