[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Crash using text property 'composite on w32
From: |
Chong Yidong |
Subject: |
Re: Crash using text property 'composite on w32 |
Date: |
Tue, 12 Jun 2007 11:44:59 -0400 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux) |
"Juanma Barranquero" <lekktu@gmail.com> writes:
> Program received signal SIGSEGV, Segmentation fault.
> 0x010c798a in run_composition_function (from=267, to=269, prop=520)
> at composite.c:456
> 456 func = COMPOSITION_MODIFICATION_FUNC (prop);
> (gdb) bt
> #0 0x010c798a in run_composition_function (from=267, to=269, prop=520)
> at composite.c:456
> #1 0x010c7d1c in update_compositions (from=269, to=271, check_mask=3)
> at composite.c:514
The trouble here is that the code expects the property `prop' obtained
from find_composition to be a valid composition, which is a cons. So
probably the way to fix this is to stick in a couple of
COMPOSITION_VALID_P checks into update_compositions, around
composite.c:514.
The strange thing, though, is that the elisp manual describes the
composition property as follows (documented by Handa on 2007-04-19):
`composition'
This text property is used to display a sequence of characters as a
single glyph composed from components. For instance, in Thai a
base consonant is composed with the following combining vowel as a
single glyph. The value should be a character or a sequence
(vector, list, or string) of integers.
* If it is a character, it means to display that character
instead of the text in the region.
* If it is a string, it means to display that string's contents
instead of the text in the region.
* If it is a vector or list, the elements are characters
interleaved with internal codes specifying how to compose the
following character with the previous one.
Is this a mistake? The assumption made in the Emacs code is that the
only valid form for a `composition' property is a cons cell. For
example, the definition of COMPOSITION_VALID_P in composite.h:96 is
#define COMPOSITION_VALID_P(start, end, prop) \
(CONSP (prop) \
&& .....
So it looks like the documentation needs to be fixed too.