[Top][All Lists]

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

[debbugs-tracker] bug#19496: closed (25.0.50; term.c, produce_composite_

From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#19496: closed (25.0.50; term.c, produce_composite_glyh, cmp->pixel_width uninitialized)
Date: Sat, 03 Jan 2015 22:41:02 +0000

Your message dated Sat, 03 Jan 2015 14:39:56 -0800
with message-id <address@hidden>
and subject line Re: bug#19496: 25.0.50; term.c, produce_composite_glyh, 
cmp->pixel_width uninitialized
has caused the debbugs.gnu.org bug report #19496,
regarding 25.0.50; term.c, produce_composite_glyh, cmp->pixel_width 
to be marked as done.

(If you believe you have received this mail in error, please contact

19496: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19496
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- 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 (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:

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.

(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))

--- End Message ---
--- Begin Message --- 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 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
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.

--- End Message ---

reply via email to

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