From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#24759: 25.1.50; electric-quote-mode Date: Sun, 23 Oct 2016 10:13:20 +0300 Message-ID: <831sz7pmgf.fsf@gnu.org> References: <83wph1qxrw.fsf@gnu.org> <74d0a4a5-014e-b365-9d89-ad03a7fc6430@cs.ucla.edu> <83shrori8z.fsf@gnu.org> <83mvhwp5mr.fsf@gnu.org> <83k2d0p485.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1477206866 25129 195.159.176.226 (23 Oct 2016 07:14:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 23 Oct 2016 07:14:26 +0000 (UTC) Cc: 24759@debbugs.gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Oct 23 09:14:21 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1byCyw-0004Xn-Qx for geb-bug-gnu-emacs@m.gmane.org; Sun, 23 Oct 2016 09:14:11 +0200 Original-Received: from localhost ([::1]:39978 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byCyz-0000l9-2Q for geb-bug-gnu-emacs@m.gmane.org; Sun, 23 Oct 2016 03:14:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55718) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byCys-0000kr-If for bug-gnu-emacs@gnu.org; Sun, 23 Oct 2016 03:14:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1byCyn-0004Vi-VI for bug-gnu-emacs@gnu.org; Sun, 23 Oct 2016 03:14:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60021) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1byCyn-0004VZ-SF for bug-gnu-emacs@gnu.org; Sun, 23 Oct 2016 03:14:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1byCyn-0001qq-MH for bug-gnu-emacs@gnu.org; Sun, 23 Oct 2016 03:14:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 23 Oct 2016 07:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24759 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 24759-submit@debbugs.gnu.org id=B24759.14772068167067 (code B ref 24759); Sun, 23 Oct 2016 07:14:01 +0000 Original-Received: (at 24759) by debbugs.gnu.org; 23 Oct 2016 07:13:36 +0000 Original-Received: from localhost ([127.0.0.1]:47185 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1byCyO-0001pv-GU for submit@debbugs.gnu.org; Sun, 23 Oct 2016 03:13:36 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:36432) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1byCyN-0001pg-Fs for 24759@debbugs.gnu.org; Sun, 23 Oct 2016 03:13:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1byCyD-0004QI-NX for 24759@debbugs.gnu.org; Sun, 23 Oct 2016 03:13:30 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58307) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byCyD-0004QE-Jo; Sun, 23 Oct 2016 03:13:25 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2449 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1byCyC-0005OH-Vt; Sun, 23 Oct 2016 03:13:25 -0400 In-reply-to: (message from Paul Eggert on Sat, 22 Oct 2016 21:10:08 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:124873 Archived-At: > Cc: 24759@debbugs.gnu.org > From: Paul Eggert > Date: Sat, 22 Oct 2016 21:10:08 -0700 > > Eli Zaretskii wrote: > > Once we have tried all those defaults, and found they cannot do the > > job, we've exhausted our potential of guessing "what the user wants" > > reliably, so we must now ask the user to tell us that. > > It is odd that Emacs uses UTF-8 without questions in the C locale, but prompts > and suggest a Chinese encoding in a unibyte French locale. I tried to explain the logic behind this in another message. > > It was like that since Emacs 20.1. I don't see what changed now that > > it's suddenly a problem. > > Emacs is now more likely to have non-unibyte text, partly due to its fancier > quoting and partly because Unicode is more ubiquitous than it was in 1997 when > Emacs 20.1 was released. So the problem is more likely to occur now. I'm not sure you are right (the original Emacs 20.x m17n was heavily biased towards ISO-2022 encodings, which are multibyte), but I don't think it matters. > > If you are hinting that UTF-8 should come up first > > UTF-8 should be the most-preferred multibyte encoding nowadays, unless there is > a reasonable indication that the user prefers something else. What kind of indication do you have in mind? > In a unibyte European locale, UTF-8 should be the first-listed > multibyte encoding by default. Why not list it the first always? That sounds simpler to me, because it doesn't require any guesswork about the user preferences beyond what we do already. The encoding we offer as the first alternative now has nothing to do with user preferences, so why would we introduce such preferences? > > Most buffers will never be saved. > > For buffers that don't correspond to files, we needn't bother with any of this > checking. But for buffers that correspond to files with restrictive encodings, > it would be helpful to warn users earlier rather than later about this sort of > problem. First, buffers that correspond to files are not the only case where this encoding prompt can pop up. Text sent to a subprocess or to the network (like this email message I'm typing) is another. And second, I think you underestimate the annoyance that would result from such prompting. If the single prompt we now issue already annoys you, it hardly makes sense to do the same multiple times. It is better to try to minimize the prompts by silently doing TRT whenever we can. > It's a bit like spelling checking. It's not. A mis-spelled buffer can be saved, but we cannot save a buffer without knowing how to encode it.