bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#30405: 26.0.91; Incorrect apostrophe translation in ImageMagick erro


From: Paul Eggert
Subject: bug#30405: 26.0.91; Incorrect apostrophe translation in ImageMagick error message
Date: Sun, 11 Feb 2018 09:26:41 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

Eli Zaretskii wrote:
Cc: address@hidden, address@hidden, address@hidden
From: Paul Eggert <address@hidden>
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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]