[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
- Re: Emacs Lisp's future, (continued)
- Re: Emacs Lisp's future, Richard Stallman, 2014/10/12
- Re: Emacs Lisp's future, Stephen J. Turnbull, 2014/10/13
- Re: Emacs Lisp's future, Richard Stallman, 2014/10/12
- Re: Emacs Lisp's future, Eli Zaretskii, 2014/10/12
- Re: Emacs Lisp's future, Richard Stallman, 2014/10/11
- Re: Emacs Lisp's future, Eli Zaretskii, 2014/10/12
- Re: Emacs Lisp's future, Richard Stallman, 2014/10/12
- Re: Emacs Lisp's future, Richard Stallman, 2014/10/12
- Re: Emacs Lisp's future,
David Kastrup <=
- Re: Emacs Lisp's future, Richard Stallman, 2014/10/11
- Re: Emacs Lisp's future, Richard Stallman, 2014/10/10
- Re: Emacs Lisp's future, Eli Zaretskii, 2014/10/10
- RE: Emacs Lisp's future, Drew Adams, 2014/10/10
- Re: Emacs Lisp's future, Eli Zaretskii, 2014/10/10
- Re: Emacs Lisp's future, Richard Stallman, 2014/10/10
- Re: Emacs Lisp's future, Eli Zaretskii, 2014/10/11
- Re: Emacs Lisp's future, Richard Stallman, 2014/10/11
- Re: Emacs Lisp's future, Eli Zaretskii, 2014/10/12
- Re: Emacs Lisp's future, David Kastrup, 2014/10/12