GNU bug report logs -
#30405
26.0.91; Incorrect apostrophe translation in ImageMagick error message
Previous Next
Reported by: Gemini Lasswell <gazally <at> runbox.com>
Date: Fri, 9 Feb 2018 21:15:01 UTC
Severity: normal
Found in versions 26.0.91, 25.1
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
Message #79 received at 30405 <at> debbugs.gnu.org (full text, mbox):
> Cc: npostavs <at> users.sourceforge.net, 30405 <at> debbugs.gnu.org, gazally <at> runbox.com
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> 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 "¢¢".
Because you shoot your self in the foot by passing a multibyte string
to 'message'. In this scenario, you are not supposed to do that, you
are supposed to use only unibyte strings.
Also, did you try the variant with 'error' instead of 'message' (in
which case you need to make *scratch* unibyte before invoking 'foo'.
> 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.
That variable's purpose is to display raw bytes as readable text, so I
definitely disagree in this specific use case.
This bug report was last modified 7 years and 92 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.