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: Sun, 11 Feb 2018 09:26:41 -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> 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 1518369927 16229 195.159.176.226 (11 Feb 2018 17:25:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 11 Feb 2018 17:25:27 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 Cc: npostavs@users.sourceforge.net, 30405@debbugs.gnu.org, gazally@runbox.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Feb 11 18:25:23 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 1ekvNG-00037K-65 for geb-bug-gnu-emacs@m.gmane.org; Sun, 11 Feb 2018 18:25:10 +0100 Original-Received: from localhost ([::1]:34444 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ekvPH-00034H-Ny for geb-bug-gnu-emacs@m.gmane.org; Sun, 11 Feb 2018 12:27:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57220) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ekvP8-00032c-KF for bug-gnu-emacs@gnu.org; Sun, 11 Feb 2018 12:27:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ekvP4-0004J1-FA for bug-gnu-emacs@gnu.org; Sun, 11 Feb 2018 12:27:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:58900) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ekvP4-0004Ie-AT for bug-gnu-emacs@gnu.org; Sun, 11 Feb 2018 12:27:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ekvP4-0004Pc-2X for bug-gnu-emacs@gnu.org; Sun, 11 Feb 2018 12:27:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 Feb 2018 17:27:02 +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.151837001216938 (code B ref 30405); Sun, 11 Feb 2018 17:27:02 +0000 Original-Received: (at 30405) by debbugs.gnu.org; 11 Feb 2018 17:26:52 +0000 Original-Received: from localhost ([127.0.0.1]:38563 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ekvOu-0004P7-Go for submit@debbugs.gnu.org; Sun, 11 Feb 2018 12:26:52 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:39808) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ekvOr-0004Or-EV for 30405@debbugs.gnu.org; Sun, 11 Feb 2018 12:26:50 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id AFB5516107F; Sun, 11 Feb 2018 09:26:43 -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 viO5wvqcnI9i; Sun, 11 Feb 2018 09:26:42 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 5BE671610A8; Sun, 11 Feb 2018 09:26:42 -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 UkQfwUNCAeSj; Sun, 11 Feb 2018 09:26:42 -0800 (PST) Original-Received: from [192.168.1.9] (unknown [47.154.30.119]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 2D7DB16107F; Sun, 11 Feb 2018 09:26:42 -0800 (PST) In-Reply-To: <83wozk1qsy.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:143157 Archived-At: Eli Zaretskii wrote: >> Cc: rgm@gnu.org, gazally@runbox.com, 30405@debbugs.gnu.org >> From: Paul Eggert >> Date: Sat, 10 Feb 2018 10:57:28 -0800 >> >> Eli Zaretskii wrote: >>> We make the echo area >>> buffer unibyte when the message is generated with the current buffer >>> being unibyte. >> >> This made sense back in the 1990s when unibyte was commonly used for t= ext. >> Nowadays, though, wouldn't it make more sense to keep the echo area mu= ltibyte? >> The echo area is intended for text, not for binary data. >=20 > I don't see how the date outside could matter here. What I was trying to say is that back in the 1990s it was relatively comm= on for=20 people to run Emacs mostly in unibyte mode and to edit files in a Latin-1= =20 locale, so it was natural for programmers to expect the echo area to be=20 consistent with the file being edited. Nowadays we live in a mostly-multi= byte=20 world, where unibyte inside Emacs is intended only for binary data, and s= o it's=20 no longer a reasonable design choice to have the echo area (which is inte= nded=20 for text messages to the user) to be unibyte (which is now intended for b= inary=20 data). > I have a guess for why we did that: it's because in Emacs 21 we > displayed raw bytes as Latin-N characters, so non-ASCII text in > unibyte strings needed a unibyte buffer to display it as expected. > But that feature is no longer available, as raw bytes are always > displayed as octal escapes. Sounds plausible. > The question that bothers me is can a unibyte string inserted or > printed into a multibyte buffer be converted to something that will > display as a non-ASCII character, not as an octal escape. Surely we can arrange for the latter.