From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Sat, 11 Oct 2014 10:33:11 +0300 Message-ID: <83y4sn83ig.fsf@gnu.org> References: <54193A70.9020901@member.fsf.org> <87wq8pwjen.fsf@uwakimon.sk.tsukuba.ac.jp> <837g0ptnlj.fsf@gnu.org> <87r3yxwdr6.fsf@uwakimon.sk.tsukuba.ac.jp> <87tx3tmi3t.fsf@fencepost.gnu.org> <834mvttgsf.fsf@gnu.org> <87lhp5m99w.fsf@fencepost.gnu.org> <87h9ztm5oa.fsf@fencepost.gnu.org> <87d2ahm3nw.fsf@fencepost.gnu.org> <871tqneyvl.fsf@netris.org> <87d2a54t1m.fsf@yeeloong.lan> <83lhotme1e.fsf@gnu.org> <871tql17uw.fsf@yeeloong.lan> <838uktm9gw.fsf@gnu.org> <87h9zgarvp.fsf@fencepost.gnu.org> <83y4srjaot.fsf@gnu.org> <83r3yhiu8c.fsf@gnu.org> <83r3yg9bpu.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1413012830 6689 80.91.229.3 (11 Oct 2014 07:33:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 11 Oct 2014 07:33:50 +0000 (UTC) Cc: dak@gnu.org, mhw@netris.org, dmantipov@yandex.ru, emacs-devel@gnu.org, handa@gnu.org, monnier@iro.umontreal.ca, stephen@xemacs.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 11 09:33:42 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XcrBO-0003g9-Ih for ged-emacs-devel@m.gmane.org; Sat, 11 Oct 2014 09:33:42 +0200 Original-Received: from localhost ([::1]:53251 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XcrBN-0001Xk-VG for ged-emacs-devel@m.gmane.org; Sat, 11 Oct 2014 03:33:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37598) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XcrBG-0001Wn-IH for emacs-devel@gnu.org; Sat, 11 Oct 2014 03:33:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XcrBC-0008Kc-5O for emacs-devel@gnu.org; Sat, 11 Oct 2014 03:33:34 -0400 Original-Received: from mtaout29.012.net.il ([80.179.55.185]:35054) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XcrB6-0008JB-SV; Sat, 11 Oct 2014 03:33:25 -0400 Original-Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0ND900K00RL7PM00@mtaout29.012.net.il>; Sat, 11 Oct 2014 10:32:29 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0ND900JPWRM5Y500@mtaout29.012.net.il>; Sat, 11 Oct 2014 10:32:29 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.185 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:175251 Archived-At: > Date: Fri, 10 Oct 2014 21:17:15 -0400 > From: Richard Stallman > 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.