|
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: 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.
[Prev in Thread] | Current Thread | [Next in Thread] |