GNU bug report logs - #19496
25.0.50; term.c, produce_composite_glyh, cmp->pixel_width uninitialized

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 19496 in the body.
You can then email your comments to 19496 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Stephen C. Gilardi" <scgilardi <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.0.50;
 term.c, produce_composite_glyh, cmp->pixel_width uninitialized
Date: Sat, 3 Jan 2015 09:20:52 -0500

emacs -Q
open an emacs lisp file that contains (lambda ... )
turn on prettify-symbols-mode
the lambda form is converted to (λ ... ), and should be displayed that way, but instead it's displayed as
(\
λ
 ...)

This commit is the first on master to show the problem: 20791069fa34b486c018ba7f27982bdc6ad2a4ea (found by git bisect)

The problem is the calculation of the pixel_width of the composition in the buffer. It's set to the pixel_width of the composition in the composition table, but that field is not initialized. (There is no mention of pixel_width anywhere in composite.c where the table entries are made.) When I check the value of cmp->pixel_width, it's somewhere near MAX_SHORT. It should be a small integer. Prior to this commit, in my setup, the value is 1 which avoids the problem, but isn't a credible pixel width.

An apparently very wide pixel_width for the composition explains the display anomaly. The composition appears to be thousands of characters wide and if that were true, the anomalous display would have been appropriate.

I don't see an obvious fix. There seems to be some confusing use in the code between "width in columns" and "width in pixels". It's possible that the pixel_width field in "struct it" is not named precisely for how it’s used--in a terminal, the width may actually be used as a number of columns rather than a number of pixels.


In GNU Emacs 25.0.50.1 (x86_64-unknown-linux-gnu)
 of 2015-01-03 on localhost
Repository revision: 20791069fa34b486c018ba7f27982bdc6ad2a4ea
System Description:	Ubuntu 14.04.1 LTS

Configured using:
 `configure --without-x'

Configured features:
SOUND GPM DBUS NOTIFY LIBSELINUX GNUTLS LIBXML2 ZLIB

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

Major mode: Emacs-Lisp

Minor modes in effect:
  diff-auto-refine-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  prettify-symbols-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Prettify-Symbols mode enabled
user-error: Beginning of history; no preceding item

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message dired 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 help-fns mail-prsvr mail-utils regexp-opt vc-git diff-mode
easymenu easy-mmode xterm time-date tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type tabulated-list newcomment elisp-mode
lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
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 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 make-network-process
dbusbind gfilenotify multi-tty emacs)

Memory information:
((conses 16 82152 5459)
 (symbols 48 17585 0)
 (miscs 40 36 102)
 (strings 32 12557 4834)
 (string-bytes 1 332483)
 (vectors 16 8665)
 (vector-slots 8 349036 23681)
 (floats 8 65 657)
 (intervals 56 259 25)
 (buffers 976 12)
 (heap 1024 37582 1315))

Message #8 received at 19496 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Stephen C. Gilardi" <scgilardi <at> gmail.com>,
 Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Kenichi Handa <handa <at> gnu.org>, 19496 <at> debbugs.gnu.org
Subject: Re: bug#19496: 25.0.50;
 term.c, produce_composite_glyh, cmp->pixel_width uninitialized
Date: Sat, 03 Jan 2015 20:17:26 +0200

> From: "Stephen C. Gilardi" <scgilardi <at> gmail.com>
> Date: Sat, 3 Jan 2015 09:20:52 -0500
> 
> emacs -Q
> open an emacs lisp file that contains (lambda ... )
> turn on prettify-symbols-mode
> the lambda form is converted to (λ ... ), and should be displayed that way, but instead it's displayed as
> (\
> λ
>  ...)
> 
> This commit is the first on master to show the problem: 20791069fa34b486c018ba7f27982bdc6ad2a4ea (found by git bisect)

I think that commit was mistaken, and should be reverted, because
before it this worked correctly.  CC'ing Paul, who made the change,
and Handa-san, who probably wrote it.

Paul, was there a use case where you saw a problem with the original
code?  If so, can you show it?

> I don't see an obvious fix.

Why do you think the previous code is not TRT?

> There seems to be some confusing use in the code between "width in columns" and "width in pixels". It's possible that the pixel_width field in "struct it" is not named precisely for how it’s used--in a terminal, the width may actually be used as a number of columns rather than a number of pixels.

On a text terminal, each glyph is 1 pixel wide.  So on a text terminal
these two are identical.

Message #13 received at 19496-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>, "Stephen C. Gilardi" <scgilardi <at> gmail.com>
Cc: Kenichi Handa <handa <at> gnu.org>, 19496-done <at> debbugs.gnu.org
Subject: Re: bug#19496: 25.0.50;
 term.c, produce_composite_glyh, cmp->pixel_width uninitialized
Date: Sat, 03 Jan 2015 14:39:56 -0800

Eli Zaretskii wrote:
> Paul, was there a use case where you saw a problem with the original
> code?  If so, can you show it?

Sorry, that was a thinko on my part.  I reverted the change in master as commit 
5395106.  Thanks for reporting it.

Previous Next

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