bug#30405: 26.0.91; Incorrect apostrophe translation in ImageMagick error message

[Paul Eggert <eggert@cs.ucla.edu>]

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.