GNU bug report logs - #30405
26.0.91; Incorrect apostrophe translation in ImageMagick error message

Previous Next

Package: emacs;

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

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
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 20:21:21 +0200

> Cc: npostavs <at> users.sourceforge.net, 30405 <at> debbugs.gnu.org, gazally <at> runbox.com
> From: Paul Eggert <eggert <at> 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.
This bug report was last modified 7 years and 93 days ago.

Previous Next

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