GNU bug report logs -
#13449
24.3.50; Perl mode composed symbols not visible
Previous Next
Reported by: Richard Copley <rcopley <at> gmail.com>
Date: Tue, 15 Jan 2013 10:19:02 UTC
Severity: normal
Found in version 24.3.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13449 in the body.
You can then email your comments to 13449 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#13449
; Package
emacs
.
(Tue, 15 Jan 2013 10:19:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Richard Copley <rcopley <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Tue, 15 Jan 2013 10:19:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
When I visit a Perl source file from `emacs -Q', the Unicode
replacements for `=>' and "::" are not visible (they appear the same as
a single space character would). The `->' character is not
affected. This happens on Windows XP. I think it does not happen on
Windows 8 or Linux (but I will check when I get the chance). Doing "M-x
set-variable perl-prettify-symbols RET nil RET" (or using
customize-variable) doesn't cause the character(s) to redisplay
differently (even if I kill the buffer and visit the file again), but if
I do (setq perl-prettify-symbols nil) from `emacs -Q' and then visit
the Perl source file, the non-prettified versions are visible.
In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600)
of 2012-11-12 on 57172UHB
Bzr revision: 110872
vincentb1 <at> users.sourceforge.net-20121112055353-v0t5ytiafc4327c8
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
`configure --with-gcc (4.6) --enable-checking --cflags
-fno-omit-frame-pointer -L c:/gnuwin32/lib -I c:/gnuwin32/include'
Important settings:
value of $EMACSDATA: c:/Emacs/emacs-110872/etc
value of $EMACSDOC: c:/Emacs/emacs-110872/etc
value of $EMACSLOADPATH:
c:/Emacs/emacs-110872/site-lisp;c:/Emacs/emacs-110872/../site-lisp;c:/Emacs/emacs-110872/lisp;c:/Emacs/emacs-110872/leim
value of $EMACSPATH: c:/Emacs/emacs-110872/bin
value of $LANG: ENG
locale-coding-system: cp1252
default enable-multibyte-characters: t
Major mode: Perl
Minor modes in effect:
tooltip-mode: t
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
line-number-mode: t
transient-mark-mode: t
Recent input:
M-x s e t SPC v a r i a b l e <return> p e r l - p
r e t t i f y - s y m b o l s <return> n i l <return>
C-x k <return> C-x C-f b u i l d . p l <return> <down-mouse-1>
<mouse-1> C-x = M-x r e p o r t - e m a c s - b u g
<return>
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Char: = (61, #o75, #x3d) point=388 of 13354 (3%) column=34
Load-path shadows:
None found.
Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils cus-edit easymenu cus-start cus-load wid-edit
help-fns perl-mode time-date tooltip ediff-hook vc-hooks lisp-float-type
mwheel dos-w32 ls-lisp w32-common-fns disp-table w32-win w32-vars
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process w32 multi-tty
emacs)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#13449
; Package
emacs
.
(Tue, 15 Jan 2013 16:22:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 13449 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 15 Jan 2013 10:17:38 +0000
> From: Richard Copley <rcopley <at> gmail.com>
>
> When I visit a Perl source file from `emacs -Q', the Unicode
> replacements for `=>' and "::" are not visible (they appear the same as
> a single space character would). The `->' character is not
> affected. This happens on Windows XP.
I cannot reproduce this on my XP SP3 box, with today's development
sources. Your Emacs is quite old (2 months ago), but I doubt that
this problem is due to some bug we had at that time.
When you go to those "space characters" and type "C-u C-x =", what
does Emacs say about these two characters in the buffer that it pops
up?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#13449
; Package
emacs
.
(Tue, 15 Jan 2013 16:42:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 13449 <at> debbugs.gnu.org (full text, mbox):
On 15 January 2013 16:21, Eli Zaretskii wrote:
> I cannot reproduce this on my XP SP3 box, with today's development
> sources. Your Emacs is quite old (2 months ago), but I doubt that
> this problem is due to some bug we had at that time.
Sorry, I should have said: the bug is still present in 111524 (early
this morning); 110872 (two months ago) was the earliest build that I
happen to have hanging around that exhibits the bug.
> When you go to those "space characters" and type "C-u C-x =", what
> does Emacs say about these two characters in the buffer that it pops
> up?
The following (except that the "=>" is not visible in the Emacs buffer):
position: 388 of 13355 (3%), column: 34
character: = (displayed as =) (codepoint 61, #o75, #x3d)
preferred charset: ascii (ASCII (ISO646 IRV))
code point in charset: 0x3D
syntax: . which means: punctuation
category: .:Base, a:ASCII, l:Latin, r:Roman
to input: type "C-x 8 RET HEX-CODEPOINT" or "C-x 8 RET NAME"
buffer code: #x3D
file code: #x3D (encoded by coding system undecided-dos)
display: composed to form "=>" (see below)
Composed with the following character(s) ">" by the rule:
(?=>)
The component character(s) are displayed by these fonts (glyph codes):
=>: uniscribe:-outline-Source Code
Pro-normal-normal-normal-mono-13-*-*-*-c-*-iso10646-1 (#x01)
See the variable `reference-point-alist' for the meaning of the rule.
Character code properties: customize what to show
name: EQUALS SIGN
general-category: Sm (Symbol, Math)
decomposition: (61) ('=')
There are text properties here:
composition [Show]
fontified t
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#13449
; Package
emacs
.
(Tue, 15 Jan 2013 16:52:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 13449 <at> debbugs.gnu.org (full text, mbox):
> The following (except that the "=>" is not visible in the Emacs buffer):
Note: my mail client changed the unicode character U+21D2 (Rightwards
Double Arrow) to "=" and ">". All the occurrences of "=>" in my last
mail should be U+21D2 (decimal 8658).
Expanding the composition property (by typing RET on [Show] in the
pop-up buffer) gives:
(1 2
[8658])
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#13449
; Package
emacs
.
(Tue, 15 Jan 2013 17:10:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 13449 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 15 Jan 2013 16:51:17 +0000
> From: Richard Copley <rcopley <at> gmail.com>
> Cc: 13449 <at> debbugs.gnu.org
>
> > The following (except that the "=>" is not visible in the Emacs buffer):
>
> Note: my mail client changed the unicode character U+21D2 (Rightwards
> Double Arrow) to "=" and ">".
No, it didn't. The text in the buffer is really 2 characters, = and >.
Emacs converts them to u+21d2 at display time. (Character compositions
are display-time feature in general.)
> Expanding the composition property (by typing RET on [Show] in the
> pop-up buffer) gives:
> (1 2
> [8658])
I get
(0 2
[8658])
but I don't think the difference matters.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#13449
; Package
emacs
.
(Tue, 15 Jan 2013 17:16:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 13449 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 15 Jan 2013 16:41:09 +0000
> From: Richard Copley <rcopley <at> gmail.com>
> Cc: 13449 <at> debbugs.gnu.org
>
> > When you go to those "space characters" and type "C-u C-x =", what
> > does Emacs say about these two characters in the buffer that it pops
> > up?
>
> The following (except that the "=>" is not visible in the Emacs buffer):
>
> position: 388 of 13355 (3%), column: 34
> character: = (displayed as =) (codepoint 61, #o75, #x3d)
> preferred charset: ascii (ASCII (ISO646 IRV))
> code point in charset: 0x3D
> syntax: . which means: punctuation
> category: .:Base, a:ASCII, l:Latin, r:Roman
> to input: type "C-x 8 RET HEX-CODEPOINT" or "C-x 8 RET NAME"
> buffer code: #x3D
> file code: #x3D (encoded by coding system undecided-dos)
> display: composed to form "=>" (see below)
>
> Composed with the following character(s) ">" by the rule:
> (?=>)
> The component character(s) are displayed by these fonts (glyph codes):
> =>: uniscribe:-outline-Source Code Pro-normal-normal-normal-mono-13-*-*-*-c-*-iso10646-1 (#x01)
So it sounds like you have a bad font, which doesn't include a glyph
for this character, but claims it does.
On my machine, Emacs uses the Arial Unicode MS font to show the
character. If you select the Arial Unicode MS font manually (via
S-mouse-1, for example), does the character display correctly?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#13449
; Package
emacs
.
(Tue, 15 Jan 2013 18:58:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 13449 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 15 Jan 2013 18:08:09 +0000
> From: Richard Copley <rcopley <at> gmail.com>
>
> It does indeed. That explains it, thank you. Deleting "Source Code
> Pro" from the Fonts folder in Windows fixes this for me. (Note for
> others reading this: since this was from `emacs -Q', the default font
> was "Courier New". The bad font "Source Code Pro" was being chosen as
> a fallback for missing glyphs.)
So can we close this bug?
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Wed, 16 Jan 2013 18:56:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Richard Copley <rcopley <at> gmail.com>
:
bug acknowledged by developer.
(Wed, 16 Jan 2013 18:56:05 GMT)
Full text and
rfc822 format available.
Message #28 received at 13449-done <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 16 Jan 2013 10:08:50 +0000
> From: Richard Copley <rcopley <at> gmail.com>
>
> > So can we close this bug?
>
> I should think so, yes. Not an Emacs bug.
Great, closing.
> Only tangentially related: would it be reasonable to mention
> `perl-prettify-symbols' in NEWS?
I guess so, but since I don't use Perl mode, I will defer to someone
who does to do that.
Thanks.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 14 Feb 2013 12:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 12 years and 131 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.