[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#30405: 26.0.91; Incorrect apostrophe translation in ImageMagick erro
From: |
Eli Zaretskii |
Subject: |
bug#30405: 26.0.91; Incorrect apostrophe translation in ImageMagick error message |
Date: |
Mon, 12 Feb 2018 20:21:21 +0200 |
> Cc: npostavs@users.sourceforge.net, 30405@debbugs.gnu.org, gazally@runbox.com
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sun, 11 Feb 2018 12:36:47 -0800
>
> > emacs -Q
> > M-x set-variable RET unibyte-display-via-language-environment RET t RET
> > M-: (set-buffer-multibyte nil) RET
> > C-q 0242 SPC
> >
> > This should display ¢.
> >
> > So I think we can get rid of making echo-area buffers unibyte, as long
> > as we make sure that variable is nil (which it is by default).
>
> 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.
> And yet this patch works without worrying about
> unibyte-display-via-language-environment, even if I run Emacs in a unibyte
> locale like en_US.iso885915 (a practice that's no longer common).
Whether the locale is unibyte or not is immaterial, because we use
multibyte representation for Latin-N characters as well. What is
important is to be in a unibyte buffer and display a message with
non-ASCII bytes, while unibyte-display-via-language-environment is
non-nil.
- bug#30405: 26.0.91; Incorrect apostrophe translation in ImageMagick error message, (continued)
- bug#30405: 26.0.91; Incorrect apostrophe translation in ImageMagick error message, Noam Postavsky, 2018/02/09
- bug#30405: 26.0.91; Incorrect apostrophe translation in ImageMagick error message, Paul Eggert, 2018/02/10
- bug#30405: 26.0.91; Incorrect apostrophe translation in ImageMagick error message, Eli Zaretskii, 2018/02/10
- bug#30405: 26.0.91; Incorrect apostrophe translation in ImageMagick error message, Paul Eggert, 2018/02/11
- bug#30405: 26.0.91; Incorrect apostrophe translation in ImageMagick error message, Eli Zaretskii, 2018/02/11
- bug#30405: 26.0.91; Incorrect apostrophe translation in ImageMagick error message, Eli Zaretskii, 2018/02/11
- bug#30405: 26.0.91; Incorrect apostrophe translation in ImageMagick error message, Paul Eggert, 2018/02/11
- bug#30405: 26.0.91; Incorrect apostrophe translation in ImageMagick error message,
Eli Zaretskii <=
- bug#30405: 26.0.91; Incorrect apostrophe translation in ImageMagick error message, Paul Eggert, 2018/02/12
- bug#30405: 26.0.91; Incorrect apostrophe translation in ImageMagick error message, Eli Zaretskii, 2018/02/12
- bug#30405: 26.0.91; Incorrect apostrophe translation in ImageMagick error message, Paul Eggert, 2018/02/12
- bug#30405: 26.0.91; Incorrect apostrophe translation in ImageMagick error message, Eli Zaretskii, 2018/02/13
- bug#30405: 26.0.91; Incorrect apostrophe translation in ImageMagick error message, Paul Eggert, 2018/02/13
- bug#30405: 26.0.91; Incorrect apostrophe translation in ImageMagick error message, Eli Zaretskii, 2018/02/13
- bug#30405: 26.0.91; Incorrect apostrophe translation in ImageMagick error message, Eli Zaretskii, 2018/02/17
- bug#30405: 26.0.91; Incorrect apostrophe translation in ImageMagick error message, Richard Stallman, 2018/02/10