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

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

bug#24637: closed (25.1; non-ascii chars fail to render in Info buffer)


From: GNU bug Tracking System
Subject: bug#24637: closed (25.1; non-ascii chars fail to render in Info buffer)
Date: Sun, 15 Dec 2019 20:19:01 +0000

Your message dated Sun, 15 Dec 2019 21:18:36 +0100
with message-id <address@hidden>
and subject line Re: bug#24637: 25.1; non-ascii chars fail to render in Info 
buffer
has caused the debbugs.gnu.org bug report #24637,
regarding 25.1; non-ascii chars fail to render in Info buffer
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden.)


-- 
24637: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=24637
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: 25.1; non-ascii chars fail to render in Info buffer Date: Fri, 7 Oct 2016 08:13:37 -0400
While reading the Emacs manual in Emacs using Info-mode, I found that non-ascii characters are displayed as octal escape sequences rather than rendered as glyphs. To repro:

- start emacs with -Q
- open the emacs manual and start a search: C-h r s
- search for a section with non-ascii chars: it requotes text typed<return>
- the found sentence reads:
> For example, it requotes text typed `like this' to text \342\200\230like this\342\200\231.
- if correctly rendered, it would read:
> For example, it requotes text typed `like this' to text ‘like this’.

If I select the text and write the region to a file, I can open that file and Emacs renders it correctly. I tried to remedy this by adding the following to my init file (and commenting out the rest of the file):

(prefer-coding-system 'utf-8)
(set-default-coding-systems 'utf-8)
(set-terminal-coding-system 'utf-8)
(set-keyboard-coding-system 'utf-8)
(setq default-buffer-file-coding-system 'utf-8)

The only effect this had was to change the default coding system for new files from utf-8-unix to utf-8. Running `describe-coding` in the Info buffer reported
> Coding system for saving this buffer: t -- raw-text-unix
both before and after adding the above settings.

I also tried both gui and terminal, with and without the above settings, and saw the octal escape sequences in all cases.

My Emacs version and configuration:

In GNU Emacs 25.1.1 (x86_64-apple-darwin15.6.0, Carbon Version 157 AppKit 1404.47)
 of 2016-09-21 built on MachineCode.local
Windowing system distributor 'Apple Inc.', version 10.11.6
Configured using:
 'configure --enable-locallisppath=/usr/local/share/emacs/site-lisp
 --infodir=/usr/local/Cellar/emacs-mac/emacs-25.1-z-mac-6.0/share/info/emacs
 --prefix=/usr/local/Cellar/emacs-mac/emacs-25.1-z-mac-6.0 --with-mac
 --enable-mac-app=/usr/local/Cellar/emacs-mac/emacs-25.1-z-mac-6.0'

Configured features:
NOTIFY ACL LIBXML2 ZLIB TOOLKIT_SCROLL_BARS

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Info

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mac-mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a. [2 times]

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml
mml-sec password-cache epg epg-config gnus-util mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util help-fns help-mode cl-loaddefs pcase
cl-lib mail-prsvr mail-utils jka-compr info easymenu mule-util time-date
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel mac-win term/common-win tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register
page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote kqueue mac multi-tty
make-network-process emacs)

Memory information:
((conses 16 113689 6270)
 (symbols 48 20181 0)
 (miscs 40 73 185)
 (strings 32 19396 4598)
 (string-bytes 1 510009)
 (vectors 16 12204)
 (vector-slots 8 426977 6597)
 (floats 8 169 118)
 (intervals 56 4622 16)
 (buffers 976 19))

--- End Message ---
--- Begin Message --- Subject: Re: bug#24637: 25.1; non-ascii chars fail to render in Info buffer Date: Sun, 15 Dec 2019 21:18:36 +0100 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
Stefan Kangas <address@hidden> writes:

> Alan Third <address@hidden> writes:
>
>> On Mon, Dec 19, 2016 at 06:18:02PM +0200, Eli Zaretskii wrote:
>>> > From: Alan Third <address@hidden>
>>> > Cc: ivan <address@hidden>,  address@hidden
>>> > Date: Mon, 19 Dec 2016 11:27:56 +0000
>>> > 
>>> > > Does anyone else see this on OS X (or on any other OS)?
>>> > 
>>> > Just checked and I get the incorrect behaviour with the upper-case UTF-8
>>> > in emacs.info's "Local Variables:" section.
>>> 
>>> Do you also have an old Texinfo?
>>
>> Yup, that’s it exactly. macOS 10.12 comes with Texinfo 4.8.
>>
>> As far as I can tell ./configure is looking for any version above 4.6.
>> I guess this is wrong, or the macOS version is broken.
>>
>> For reference, I used homebrew to install 6.3 and this fixed it:
>>
>>     brew install texinfo
>>     brew link texinfo --force
>>
>> There are some warnings about linking in the upgraded version, but I
>> can’t really see what difference it makes, and I’m not sure whether
>> people building Emacs within homebrew itself will need to perform that
>> step.
>
> If I read this correctly, the problem is with an old version of
> texinfo (perhaps only on macOS).  If that is the case, this is not a
> bug in Emacs and should be closed?

More information was requested, but none was given within 5 weeks, so
I'm closing this bug.  If this is still an issue, please reply to this
email (use "Reply to all" in your email client) and we can reopen the
bug report.

Best regards,
Stefan Kangas


--- End Message ---

reply via email to

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