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: Mon, 12 Feb 2018 12:31:55 -0800 Organization: UCLA Computer Science Department Message-ID: <78c6e835-d516-3e40-37d1-2486ed304019@cs.ucla.edu> 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> 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 1518467487 24892 195.159.176.226 (12 Feb 2018 20:31:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 12 Feb 2018 20:31:27 +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 Mon Feb 12 21:31:22 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 1elKkw-0005cC-GC for geb-bug-gnu-emacs@m.gmane.org; Mon, 12 Feb 2018 21:31:18 +0100 Original-Received: from localhost ([::1]:49797 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1elKms-0000yA-Ge for geb-bug-gnu-emacs@m.gmane.org; Mon, 12 Feb 2018 15:33:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46224) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1elKmh-0000ws-Ea for bug-gnu-emacs@gnu.org; Mon, 12 Feb 2018 15:33:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1elKmc-0002I3-FT for bug-gnu-emacs@gnu.org; Mon, 12 Feb 2018 15:33:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60418) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1elKmc-0002Hl-Cn for bug-gnu-emacs@gnu.org; Mon, 12 Feb 2018 15:33:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1elKmb-0008Os-TX for bug-gnu-emacs@gnu.org; Mon, 12 Feb 2018 15:33: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: Mon, 12 Feb 2018 20:33: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.151846752632224 (code B ref 30405); Mon, 12 Feb 2018 20:33:01 +0000 Original-Received: (at 30405) by debbugs.gnu.org; 12 Feb 2018 20:32:06 +0000 Original-Received: from localhost ([127.0.0.1]:40082 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1elKlh-0008Ng-Up for submit@debbugs.gnu.org; Mon, 12 Feb 2018 15:32:06 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:40964) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1elKle-0008N9-RB for 30405@debbugs.gnu.org; Mon, 12 Feb 2018 15:32:04 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 794931600F3; Mon, 12 Feb 2018 12:31:56 -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 nLtDWl2lOw5z; Mon, 12 Feb 2018 12:31:55 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id B87F5160156; Mon, 12 Feb 2018 12:31:55 -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 mpIRcQ-HEHdi; Mon, 12 Feb 2018 12:31:55 -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 9EB771600F3; Mon, 12 Feb 2018 12:31:55 -0800 (PST) In-Reply-To: <836072yo6z.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:143223 Archived-At: On 02/12/2018 11:59 AM, Eli Zaretskii wrote: > unibyte-display-via-language-environment > explicitly requests display of raw bytes as Latin-1 characters, and it > requests that everywhere, including the echo area and whatnot. That's not how Emacs works, at least not in my experience. For example,=20 on current emacs-26: =C2=A0=C2=A0 emacs -Q =C2=A0=C2=A0 M-x set-variable RET unibyte-display-via-language-environme= nt RET t RET =C2=A0=C2=A0 (defun foo () =C2=A0=C2=A0=C2=A0=C2=A0 (interactive) =C2=A0=C2=A0=C2=A0=C2=A0 (message "cannot \xA2\u00A2")) C-j =C2=A0=C2=A0 M-x foo RET This displays "\242=C2=A2", not "=C2=A2=C2=A2". No doubt this isn't documented as well as it should be, but from looking=20 at the source code get_next_display_element it's clear that=20 unibyte-display-via-language-environment does not simply display every=20 raw byte as a Latin-1 character; instead, the code also takes context=20 into account, and if the context is multibyte then=20 unibyte-display-via-language-environment is ignored. Since the echo=20 area's context is text and not binary data, the display of raw bytes in=20 the echo area should be unaffected by=20 unibyte-display-via-language-environment.