GNU bug report logs - #30405
26.0.91; Incorrect apostrophe translation in ImageMagick error message

Previous Next

Full log

Message #55 received at 30405 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rgm <at> gnu.org, 30405 <at> debbugs.gnu.org, gazally <at> runbox.com,
 npostavs <at> users.sourceforge.net
Subject: Re: bug#30405: 26.0.91; Incorrect apostrophe translation in
 ImageMagick error message
Date: Sun, 11 Feb 2018 09:26:41 -0800

Eli Zaretskii wrote:
>> Cc: rgm <at> gnu.org, gazally <at> runbox.com, 30405 <at> debbugs.gnu.org
>> From: Paul Eggert <eggert <at> cs.ucla.edu>
>> 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 text.
>> Nowadays, though, wouldn't it make more sense to keep the echo area multibyte?
>> The echo area is intended for text, not for binary data.
> 
> 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 common for 
people to run Emacs mostly in unibyte mode and to edit files in a Latin-1 
locale, so it was natural for programmers to expect the echo area to be 
consistent with the file being edited. Nowadays we live in a mostly-multibyte 
world, where unibyte inside Emacs is intended only for binary data, and so it's 
no longer a reasonable design choice to have the echo area (which is intended 
for text messages to the user) to be unibyte (which is now intended for binary 
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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.