Re: Emacs Lisp's future

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 10 Oct 2014 21:17:15 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: dak@gnu.org, mhw@netris.org, dmantipov@yandex.ru,
> 	emacs-devel@gnu.org, handa@gnu.org, monnier@iro.umontreal.ca,
> 	stephen@xemacs.org
> 
>     Originally, Emacs would complain that Latin-1 cannot be used, and
>     asked the user to select a different encoding.
> 
> That is about Latin-1.  What did Emacs do, at that time, with UTF-8?

The situation I described is with text encodable by UTF-8, but not by
Latin-1.  So it has no analogue when UTF-8 is used to begin with.

> 						    Then users of UTF-8
>     locales complained that these prompts were annoyances, that they
>     expect Emacs to use UTF-8 silently, without any questions, as long as
>     UTF-8 can encode the result.
> 
> It is not clear what "As long as UTF-8 can encode the result" means,
> concretely.  Whether Emacs's UTF-8 encoding can encode the raw bytes
> is a matter of our decision.  Strictly speaking, UTF-8 can't encode
> the raw bytes.

I wasn't talking about raw bytes, I was talking about characters
outside of Latin-1 charset, like Cyrillic or Polish.

>     >     > What exactly did we try before?
>     > 
>     > and you responded
>     > 
>     >     AFAIR, we tried converting raw bytes into valid non-ASCII characters,
>     >     and perhaps also replacing them with the equivalent of u+FFFD, the
>     >     Unicode "replacement character".
>     > 
>     > But those are both different from the proposal I'm discussing.
> 
>     How are they different?
> 
> The first of them was to convert the raw bytes into valid non-ASCII characters.
> (When?  When reading the file?  When writing the file?)  You have not
> described that behavior clearly, but either way it is not the same as
> the proposal we are discussing now.  This proposal is to ask for
> confirmation before encoding a file with raw bytes.

Our experience with such prompts is that they are perceived as
annoyances, no matter whether they happen at read or at write time.

> The second was to "replace" these codes with something else.  (When?
> When reading the file?  When writing the file?)  Either way it is not
> the same as the proposal we are discussing now.  This proposal does
> not replace any characters.

What will Emacs do, under this proposal, if the user is asked whether
to keep the original raw bytes and answers NO?  I thought Emacs will
replace those invalid sequences with something, therefore I reminded
what happened last time we tried something similar.

Moreover, I think at least some of the suggestions in this thread,
perhaps not from you, were not to ask any questions at all, and
"handle" these invalid sequences automatically when Emacs reads the
text from its source, whatever that is.  Under that suggestion, the
only reasonable behavior is to replace the invalid sequences with
special valid characters, such as u+FFFD, which resembles what we
tried doing in the past.

>     In any case, I hope you are not expecting to hear about user reactions
>     to any of the proposals that haven't been tried yet.
> 
> That idea did not come from me.  YOU said they had already reacted to
> THIS proposal.

Then my imperfect wording caused your misunderstanding, for which I'm
sorry.

>       What I (and I think also David)
>     were trying to show is that _similar_ situations were met with user
>     complaints and outcry, and that we are where we are today because we
>     heeded to those complaints.
> 
> There are many ways for two different designs to be "similar".  They
> are also different.  The details are crucial for users' reactions.  I
> think the people who objected to those behaviors, which involved
> changing the file contents, might not mind the confirmation much.

Well, this is where we disagree, and as I mentioned, such
disagreements cannot be reconciled when our degrees of reliance on
past experience in similar situations is different.