From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: bug#30405: 26.0.91; Incorrect apostrophe translation in ImageMagick error message Date: Tue, 13 Feb 2018 09:43:34 -0800 Organization: UCLA Computer Science Department Message-ID: References: <874lmpzx1t.fsf@runbox.com> <87po5dczl1.fsf@users.sourceforge.net> <83tvup2q7u.fsf@gnu.org> <2061ef0c-de4d-d8c1-aea8-786223e59c7e@cs.ucla.edu> <83wozk1qsy.fsf@gnu.org> <8337271jz0.fsf@gnu.org> <83zi4fz91t.fsf@gnu.org> <3db2fa4f-fe6b-a5db-599e-b0bcd0b8511b@cs.ucla.edu> <83a7weyspq.fsf@gnu.org> <9c0033de-9afc-13f9-57cd-7970eb3cb07c@cs.ucla.edu> <836072yo6z.fsf@gnu.org> <78c6e835-d516-3e40-37d1-2486ed304019@cs.ucla.edu> <834lmlzdk8.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1518546465 3490 195.159.176.226 (13 Feb 2018 18:27:45 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 13 Feb 2018 18:27:45 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 Cc: gazally@runbox.com, 30405@debbugs.gnu.org, npostavs@users.sourceforge.net To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Feb 13 19:27:40 2018 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 1elfIn-0000Kg-OQ for geb-bug-gnu-emacs@m.gmane.org; Tue, 13 Feb 2018 19:27:37 +0100 Original-Received: from localhost ([::1]:32855 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1elfKn-0001xq-Bd for geb-bug-gnu-emacs@m.gmane.org; Tue, 13 Feb 2018 13:29:41 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39494) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1elecf-00020a-D9 for bug-gnu-emacs@gnu.org; Tue, 13 Feb 2018 12:44:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1elecc-0001bg-8s for bug-gnu-emacs@gnu.org; Tue, 13 Feb 2018 12:44:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:33818) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1elecc-0001bX-3p for bug-gnu-emacs@gnu.org; Tue, 13 Feb 2018 12:44:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1elecb-0005iD-Ti for bug-gnu-emacs@gnu.org; Tue, 13 Feb 2018 12:44:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Feb 2018 17:44:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 30405 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 30405-submit@debbugs.gnu.org id=B30405.151854382621926 (code B ref 30405); Tue, 13 Feb 2018 17:44:01 +0000 Original-Received: (at 30405) by debbugs.gnu.org; 13 Feb 2018 17:43:46 +0000 Original-Received: from localhost ([127.0.0.1]:41715 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1elecL-0005hZ-Q1 for submit@debbugs.gnu.org; Tue, 13 Feb 2018 12:43:46 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:43032) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1elecI-0005hJ-N7 for 30405@debbugs.gnu.org; Tue, 13 Feb 2018 12:43:43 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 817D1160D39; Tue, 13 Feb 2018 09:43:35 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Tt_Lk7G5bey7; Tue, 13 Feb 2018 09:43:34 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id BAC12160E18; Tue, 13 Feb 2018 09:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id RDOPVScBPiQo; Tue, 13 Feb 2018 09:43:34 -0800 (PST) Original-Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 9CF94160D39; Tue, 13 Feb 2018 09:43:34 -0800 (PST) In-Reply-To: <834lmlzdk8.fsf@gnu.org> Content-Language: en-US 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:143254 Archived-At: On 02/12/2018 09:03 PM, Eli Zaretskii wrote: > In this scenario, you are not supposed to do that, you > are supposed to use only unibyte strings. In that case the user should set the echo area to be unibyte, and if=20 there's not a convenient way to do that then we should supply one. In=20 the meantime Emacs is messed up, since it just guesses whether the echo=20 area should be unibyte and (as we've seen) it guesses wrong in common cas= es. > Also, did you try the variant with 'error' instead of 'message' (in > which case you need to make*scratch* unibyte before invoking 'foo'. In that setup in the emacs-26 branch, (error "\xA2\u00A2") displays "=C2=A2= =C2=A2"=20 in the echo area and "\242=C2=A2" in *Backtrace* and "\300\242\302\242" i= n=20 *Messages*, which is bogus. The 'message' variant displays "\242=C2=A2" i= n=20 all three places; this is much better behavior. >> Since the echo area's context is text and not binary data, the >> display of raw bytes in the echo area should be unaffected by >> unibyte-display-via-language-environment. > That variable's purpose is to display raw bytes as readable text, so I > definitely disagree in this specific use case. The abovementioned test case establishes that the variable does not in=20 fact always cause Emacs to display raw bytes as readable text. The only=20 question is whether the documentation is wrong, or the code (or both=20 :-). I've given a consistent interpretation that the intent of the=20 variable is to display raw bytes as text when in a unibyte context=20 (which the echo area is not). I haven't seen an alternative consistent=20 interpretation that's corresponds to the behavior Emacs currently=20 exhibits (i.e., the sort of behavior that elicited this bug report).