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

Previous Next

Package: emacs;

Reported by: Gemini Lasswell <gazally <at> runbox.com>

Date: Fri, 9 Feb 2018 21:15:01 UTC

Severity: normal

Found in versions 26.0.91, 25.1

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gazally <at> runbox.com, 30405 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: bug#30405: 26.0.91; Incorrect apostrophe translation in ImageMagick error message
Date: Tue, 13 Feb 2018 09:43:34 -0800
On 02/12/2018 09:03 PM, Eli Zaretskii wrote:
> In this scenario, you are not supposed to do that, you
> are supposed to use only unibyte strings.

In that case the user should set the echo area to be unibyte, and if 
there's not a convenient way to do that then we should supply one. In 
the meantime Emacs is messed up, since it just guesses whether the echo 
area should be unibyte and (as we've seen) it guesses wrong in common cases.

> Also, did you try the variant with 'error' instead of 'message' (in
> which case you need to make*scratch*  unibyte before invoking 'foo'.

In that setup in the emacs-26 branch, (error "\xA2\u00A2") displays "¢¢" 
in the echo area and "\242¢" in *Backtrace* and "\300\242\302\242" in 
*Messages*, which is bogus. The 'message' variant displays "\242¢" in 
all three places; this is much better behavior.

>> Since the echo area's context is text and not binary data, the
>> display of raw bytes in the echo area should be unaffected by
>> unibyte-display-via-language-environment.
> That variable's purpose is to display raw bytes as readable text, so I
> definitely disagree in this specific use case.

The abovementioned test case establishes that the variable does not in 
fact always cause Emacs to display raw bytes as readable text. The only 
question is whether the documentation is wrong, or the code (or both 
:-). I've given a consistent interpretation that the intent of the 
variable is to display raw bytes as text when in a unibyte context 
(which the echo area is not). I haven't seen an alternative consistent 
interpretation that's corresponds to the behavior Emacs currently 
exhibits (i.e., the sort of behavior that elicited this bug report).





This bug report was last modified 7 years and 151 days ago.

Previous Next


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