emacs-devel
[Top][All Lists]
Advanced

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

Re: Emacs Lisp's future


From: Eli Zaretskii
Subject: Re: Emacs Lisp's future
Date: Fri, 10 Oct 2014 18:38:21 +0300

> Date: Fri, 10 Oct 2014 10:24:37 -0400
> From: Richard Stallman <address@hidden>
> CC: address@hidden, address@hidden, address@hidden,
>       address@hidden, address@hidden, address@hidden,
>       address@hidden
> 
>     > Asking about invalid UTF-8 in a file could be a nuisance, but how much
>     > of a nuisance depends on the details of what we do.  Since this has
>     > some security implications, it is worth a small amount of nuisance.
> 
>     That wasn't what users felt, overwhelmingly.
> 
> Felt when?

When we tried to be more cautious about these issues than we are now.

> About what behavior?

There are several examples, and I'm not sure I recall all the details
accurately.

One such situation goes like this:

  Visit a file (or receive from another process text) that is encoded
  in Latin-1.

  Insert some text that cannot be encoded in Latin-1, and try saving
  the buffer (or sending it to a process).

Originally, Emacs would complain that Latin-1 cannot be used, and
asked the user to select a different encoding.  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.  So now that is what we do.

> I asked
> 
>     > 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?

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.  Such
expectations are IMO unreasonable.  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.  I see no reason to believe that user
reaction to the proposals being brought up here will be any different,
just because we tell them "it's about their security" and "trust us,
we know better".  Of course, one can reject the analogies and claim
that "this is different" and/or "this time the reaction will be
different", and there's nothing I could produce as counter-argument to
that except gut feelings based on our previous experience.



reply via email to

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