bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#30405: 26.0.91; Incorrect apostrophe translation in ImageMagick erro


From: Paul Eggert
Subject: bug#30405: 26.0.91; Incorrect apostrophe translation in ImageMagick error message
Date: Mon, 12 Feb 2018 11:34:13 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

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.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]