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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: rgm <at> gnu.org, 30405 <at> debbugs.gnu.org, gazally <at> runbox.com, npostavs <at> users.sourceforge.net
Subject: bug#30405: 26.0.91; Incorrect apostrophe translation in ImageMagick error message
Date: Sat, 10 Feb 2018 23:24:29 +0200

> 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.  If you understand
the reason behind the code in question, please describe it, and we can
then discuss whether that reason is still valid in the current
codebase.

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.

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.

Previous Next

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