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 11:34:13 -0800

On 02/12/2018 10:21 AM, Eli Zaretskii wrote:
>> Getting rid of it sounds good, but why do we need to worry about 
>> unibyte-display-via-language-environment? 
> Because with your patch the following doesn't work as it did before: 
> emacs -Q M-x set-variable RET unibyte-display-via-language-environment 
> RET t RET M-: (set-buffer-multibyte nil) RET (defun foo () 
> (interactive) (message "cannot ¢")) C-j M-x foo RET (To insert ¢, type 
> "C-q 0242".) And the same if you replace 'message' with 'error'. With 
> your patch, I see an octal escape, not ¢, i.e. the effect of 
> unibyte-display-via-language-environment is lost. 

That's OK, as the effect is intended for unibyte buffers and strings 
which are intended for binary data, whereas the echo area is intended to 
be text. That is, you're correct that there is a change in behavior 
here; the change is an improvement.

The example that you gave is more clearly formulated as follows:

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

because the message deliberately contains the binary byte with octal 
value 242. It's more appropriate for this example to display "\242" in 
the echo area than to display "¢", because the echo area is text, not 
binary data.

Previous Next

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