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 11:51:50 +0300 Message-ID: <83zilvo3bt.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> <831sz7pmgf.fsf@gnu.org> <2ee8a0d1-46b8-3b44-3721-806538daca82@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1477212802 3840 195.159.176.226 (23 Oct 2016 08:53:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 23 Oct 2016 08:53:22 +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 10:53:16 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 1byEWj-000855-Kp for geb-bug-gnu-emacs@m.gmane.org; Sun, 23 Oct 2016 10:53:09 +0200 Original-Received: from localhost ([::1]:40179 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byEWm-0004s5-28 for geb-bug-gnu-emacs@m.gmane.org; Sun, 23 Oct 2016 04:53:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38152) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byEWf-0004rw-TL for bug-gnu-emacs@gnu.org; Sun, 23 Oct 2016 04:53:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1byEWc-000266-R1 for bug-gnu-emacs@gnu.org; Sun, 23 Oct 2016 04:53:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60264) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1byEWc-00025X-My for bug-gnu-emacs@gnu.org; Sun, 23 Oct 2016 04:53:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1byEWc-0004H5-EH for bug-gnu-emacs@gnu.org; Sun, 23 Oct 2016 04:53:02 -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 08:53:02 +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.147721272516360 (code B ref 24759); Sun, 23 Oct 2016 08:53:02 +0000 Original-Received: (at 24759) by debbugs.gnu.org; 23 Oct 2016 08:52:05 +0000 Original-Received: from localhost ([127.0.0.1]:47426 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1byEVh-0004Fo-Ie for submit@debbugs.gnu.org; Sun, 23 Oct 2016 04:52:05 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:46996) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1byEVg-0004FG-8P for 24759@debbugs.gnu.org; Sun, 23 Oct 2016 04:52:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1byEVX-0001cq-Uy for 24759@debbugs.gnu.org; Sun, 23 Oct 2016 04:51:59 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59112) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byEVX-0001cm-Ro; Sun, 23 Oct 2016 04:51:55 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2524 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1byEVX-0005cN-67; Sun, 23 Oct 2016 04:51:55 -0400 In-reply-to: <2ee8a0d1-46b8-3b44-3721-806538daca82@cs.ucla.edu> (message from Paul Eggert on Sun, 23 Oct 2016 01:24:15 -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:124876 Archived-At: > Cc: 24759@debbugs.gnu.org > From: Paul Eggert > Date: Sun, 23 Oct 2016 01:24:15 -0700 > > > What kind of indication do you have in mind? > > A locale that uses some non-UTF-8 multibyte encoding. It isn't clear that this will help. If that locale's encoding can encode the offending characters, Emacs will already use it silently without any prompts. Beyond that, inferring a preference for some non-UTF-8 encoding from the fact that the locale's encoding is multibyte and not UTF-8 sounds far-fetched to me. > >> In a unibyte European locale, UTF-8 should be the first-listed > >> multibyte encoding by default. > > > > Why not list it the first always? > > I wouldn't object. People who prefer non-UTF-8 multibyte locales might not like > it (I'm not such a person so I can't say). I don't think we should do this as the first approximation; we should just make sure UTF-8 is the first in the list. If later users will complain about this, we could introduce a defcustom for such a "second best" encoding, perhaps with a suitably guessed default value. But I wouldn't go there without specific requests and use cases. > > If the single prompt we now issue already annoys > > you, it hardly makes sense to do the same multiple times. > > It's not merely the prompt that annoys me. It's that the prompt can occur long > after the problem it diagnoses. But the buffer we pop up clearly shows the problematic characters, and also describes which of them couldn't be encoded with what coding-systems that were tried. So I think this provides enough information for the user to decide what to do, and the fact that the insertion happened much earlier doesn't matter, because the information is not lost. In particular, one of the valid reactions to the prompt is to type C-g, then go to the buffer and delete/replace the offending characters, and then try saving again. > We could suppress the prompt in later occurrences if the user doesn't want to > see it again. We could, but it's not a yes/no kind of answer, because the user might not want to see another prompt for characters that require an encoding she already saw, but might still want prompts for characters that require other encodings. For example, if I insert a Latin-1 character, I will be prompted and decode I don't want to see prompts about any other characters that are encodable with ISO-8859-1. But if I later insert a character that cannot be encoded with ISO-8859-1, I might still want to see the prompt. So I think this is a lot of hassle for something that works well in practice for the past several years. Changing it will most probably open a can of worms (the current situation took several iterations to get right). So I'd rather we invest our efforts in silently doing TRT in more use cases.