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: 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: Mon, 12 Feb 2018 12:31:55 -0800

On 02/12/2018 11:59 AM, Eli Zaretskii wrote:
> unibyte-display-via-language-environment
> explicitly requests display of raw bytes as Latin-1 characters, and it
> requests that everywhere, including the echo area and whatnot.

That's not how Emacs works, at least not in my experience. For example, 
on current emacs-26:

   emacs -Q
   M-x set-variable RET unibyte-display-via-language-environment RET t RET
   (defun foo ()
     (interactive)
     (message "cannot \xA2\u00A2")) C-j
   M-x foo RET

This displays "\242¢", not "¢¢".

No doubt this isn't documented as well as it should be, but from looking 
at the source code get_next_display_element it's clear that 
unibyte-display-via-language-environment does not simply display every 
raw byte as a Latin-1 character; instead, the code also takes context 
into account, and if the context is multibyte then 
unibyte-display-via-language-environment is ignored. 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.

Previous Next

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