bug#30405: 26.0.91; Incorrect apostrophe translation in ImageMagick error message

[Paul Eggert <eggert@cs.ucla.edu>]

Eli Zaretskii wrote:
>> Cc: rgm@gnu.org, gazally@runbox.com, 30405@debbugs.gnu.org
>> From: Paul Eggert <eggert@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.