* Crash using text property 'composite on w32
@ 2007-06-11 16:32 Lennart Borgman (gmail)
2007-06-11 23:49 ` Jason Rumney
0 siblings, 1 reply; 11+ messages in thread
From: Lennart Borgman (gmail) @ 2007-06-11 16:32 UTC (permalink / raw)
To: bug-gnu-emacs
Evaluating the code below in the scratch buffer makes Emacs crash for
me. There is no backtrace. I start with "emacs -Q":
(let ((s "text"))
(put-text-property 0 2 'composition ?A s)
(insert s))
If the crash comes in (insert s).
In GNU Emacs 22.1.1 (i386-mingw-nt5.1.2600)
of 2007-06-04
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include'
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Crash using text property 'composite on w32
2007-06-11 16:32 Crash using text property 'composite on w32 Lennart Borgman (gmail)
@ 2007-06-11 23:49 ` Jason Rumney
2007-06-11 23:58 ` Lennart Borgman (gmail)
2007-06-12 0:07 ` Juanma Barranquero
0 siblings, 2 replies; 11+ messages in thread
From: Jason Rumney @ 2007-06-11 23:49 UTC (permalink / raw)
To: Lennart Borgman (gmail); +Cc: bug-gnu-emacs
Lennart Borgman (gmail) wrote:
>
> There is no backtrace.
Are you configuring with --no-debug again?
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Crash using text property 'composite on w32
2007-06-11 23:49 ` Jason Rumney
@ 2007-06-11 23:58 ` Lennart Borgman (gmail)
2007-06-12 0:04 ` Jason Rumney
2007-06-12 0:07 ` Juanma Barranquero
1 sibling, 1 reply; 11+ messages in thread
From: Lennart Borgman (gmail) @ 2007-06-11 23:58 UTC (permalink / raw)
To: Jason Rumney; +Cc: bug-gnu-emacs
Jason Rumney wrote:
> Lennart Borgman (gmail) wrote:
>> There is no backtrace.
>
> Are you configuring with --no-debug again?
No. I included the configure line in the message I sent:
In GNU Emacs 22.1.1 (i386-mingw-nt5.1.2600)
of 2007-06-04
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include'
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Crash using text property 'composite on w32
2007-06-11 23:58 ` Lennart Borgman (gmail)
@ 2007-06-12 0:04 ` Jason Rumney
0 siblings, 0 replies; 11+ messages in thread
From: Jason Rumney @ 2007-06-12 0:04 UTC (permalink / raw)
To: Lennart Borgman (gmail); +Cc: bug-gnu-emacs
Lennart Borgman (gmail) wrote:
> Jason Rumney wrote:
>> Lennart Borgman (gmail) wrote:
>>> There is no backtrace.
>>
>> Are you configuring with --no-debug again?
>
> No. I included the configure line in the message I sent:
So why don't you get a backtrace when it crashes under gdb?
Aside: As you'd obviously removed the machine name from the second line,
I wasn't sure that you hadn't removed something else as well.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Crash using text property 'composite on w32
2007-06-11 23:49 ` Jason Rumney
2007-06-11 23:58 ` Lennart Borgman (gmail)
@ 2007-06-12 0:07 ` Juanma Barranquero
2007-06-12 0:30 ` Lennart Borgman (gmail)
2007-06-12 15:44 ` Chong Yidong
1 sibling, 2 replies; 11+ messages in thread
From: Juanma Barranquero @ 2007-06-12 0:07 UTC (permalink / raw)
To: Jason Rumney; +Cc: bug-gnu-emacs
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
#2 0x01088a00 in general_insert_function (insert_func=0x10e8e95 <insert>,
insert_from_string_func=0x10e8c24 <insert_from_string>, inherit=0,
nargs=1, args=0x82f4d0) at editfns.c:2167
#3 0x01088a98 in Finsert (nargs=1, args=0x82f4d0) at editfns.c:2211
#4 0x0100b668 in Feval (form=26046389) at eval.c:2331
#5 0x0100b936 in Fprogn (args=26046397) at eval.c:447
#6 0x0100dbc9 in Flet (args=26033181) at eval.c:1064
#7 0x0100b72f in Feval (form=26033213) at eval.c:2275
#8 0x0100c13c in Ffuncall (nargs=2, args=0x82f7a0) at eval.c:2997
#9 0x0110c9a3 in Fbyte_code (bytestr=18775043, vector=18775060, maxdepth=64)
at bytecode.c:679
#10 0x0100ba26 in funcall_lambda (fun=18775004, nargs=1, arg_vector=0x82f8f4)
at eval.c:3184
#11 0x0100bf1b in Ffuncall (nargs=2, args=0x82f8f0) at eval.c:3054
#12 0x0110c9a3 in Fbyte_code (bytestr=18775539, vector=18775556, maxdepth=32)
at bytecode.c:679
#13 0x0100ba26 in funcall_lambda (fun=18775500, nargs=1, arg_vector=0x82fa84)
at eval.c:3184
#14 0x0100bf1b in Ffuncall (nargs=2, args=0x82fa80) at eval.c:3054
#15 0x0110b634 in Fcall_interactively (function=24232633,
record_flag=23803905, keys=23867396) at callint.c:860
#16 0x01055a20 in Fcommand_execute (cmd=24232633, record_flag=23803905,
keys=23803905, special=23803905) at keyboard.c:10119
#17 0x0105c7da in command_loop_1 () at keyboard.c:1873
#18 0x0100a347 in internal_condition_case (bfun=0x105c486 <command_loop_1>,
handlers=23872137, hfun=0x105645e <cmd_error>) at eval.c:1481
#19 0x01050656 in command_loop_2 () at keyboard.c:1329
#20 0x0100a27c in internal_catch (tag=23862273,
func=0x1050633 <command_loop_2>, arg=23803905) at eval.c:1222
#21 0x010504a3 in command_loop () at keyboard.c:1308
#22 0x01050537 in recursive_edit_1 () at keyboard.c:1006
#23 0x0105061c in Frecursive_edit () at keyboard.c:1067
#24 0x01002a2b in main (argc=3, argv=0xf726e0) at emacs.c:1768
#25 0x01001247 in __mingw_CRTStartup ()
#26 0x01001298 in mainCRTStartup ()
#27 0x7c816fd7 in _end__ ()
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Crash using text property 'composite on w32
2007-06-12 0:07 ` Juanma Barranquero
@ 2007-06-12 0:30 ` Lennart Borgman (gmail)
2007-06-12 3:19 ` Eli Zaretskii
2007-06-12 15:44 ` Chong Yidong
1 sibling, 1 reply; 11+ messages in thread
From: Lennart Borgman (gmail) @ 2007-06-12 0:30 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: bug-gnu-emacs
Juanma Barranquero wrote:
> 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
Ah, thanks. I am not familiar with gdb.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Crash using text property 'composite on w32
2007-06-12 0:30 ` Lennart Borgman (gmail)
@ 2007-06-12 3:19 ` Eli Zaretskii
2007-06-12 10:28 ` Lennart Borgman (gmail)
0 siblings, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2007-06-12 3:19 UTC (permalink / raw)
To: Lennart Borgman (gmail); +Cc: lekktu, bug-gnu-emacs
> Date: Tue, 12 Jun 2007 02:30:23 +0200
> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> Cc: bug-gnu-emacs@gnu.org
>
> Juanma Barranquero wrote:
> > 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
>
> Ah, thanks. I am not familiar with gdb.
You could also configure drmingw.exe (from mingw-utils-0.3.tar.gz) as
your JIT debugger. This is what I get from it if I try your recipe:
emacs.exe caused an Access Violation at location 010c76ca in module emacs.exe Reading from location 00000208.
Registers:
eax=00000208 ebx=00000050 ecx=00000208 edx=00000208 esi=0000004e edi=00000052
eip=010c76ca esp=0082f3c0 ebp=0082f408 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
Call stack:
010C76CA emacs.exe:010C76CA run_composition_function composite.c:456
static void run_composition_function(
int from = ,
int to = ,
Lisp_Object prop = 520
)
...
int start, end;
> func = COMPOSITION_MODIFICATION_FUNC (prop);
/* If an invalid composition precedes or follows, try to make them
valid too. */
...
010C7A5C emacs.exe:010C7A5C update_compositions composite.c:517
void update_compositions(
int from = 80,
int to = 82,
int check_mask = 3
)
...
}
> if (check_mask & CHECK_INSIDE)
{
/* In this case, we are sure that (check & CHECK_TAIL) is also
...
0108871A emacs.exe:0108871A general_insert_function editfns.c:2178
static void general_insert_function(
void ()(void) * insert_func = &insert,
void ()(void) * insert_from_string_func = &insert_from_string,
int inherit = 0,
int nargs = 1,
Lisp_Object * args = &30034243
)
...
else if (STRINGP (val))
{
> (*insert_from_string_func) (val, 0, 0,
SCHARS (val),
SBYTES (val),
...
010887B2 emacs.exe:010887B2 Finsert editfns.c:2223
Lisp_Object Finsert(
int nargs = 1,
Lisp_Object * args = &30034243
)
...
{
general_insert_function (insert, insert_from_string, 0, nargs, args);
> return Qnil;
}
...
0100B5D9 emacs.exe:0100B5D9 Feval eval.c:2331
Lisp_Object Feval(
Lisp_Object form = 30228989
)
...
goto done;
case 2:
> val = (*XSUBR (fun)->function) (argvals[0], argvals[1]);
goto done;
case 3:
...
0100B8A7 emacs.exe:0100B8A7 Fprogn eval.c:448
Lisp_Object Fprogn(
Lisp_Object args = 30228981
)
...
{
val = Feval (XCAR (args));
> args = XCDR (args);
}
...
0100DB3A emacs.exe:0100DB3A Flet eval.c:1065
Lisp_Object Flet(
Lisp_Object args = 30228909
)
...
elt = Fprogn (Fcdr (args));
> return unbind_to (count, elt);
}
...
0100B6A0 emacs.exe:0100B6A0 Feval eval.c:2275
Lisp_Object Feval(
Lisp_Object form = 30228877
)
...
{
backtrace.evalargs = 0;
> val = (*XSUBR (fun)->function) (args_left);
goto done;
}
...
0100C0AD emacs.exe:0100C0AD Ffuncall eval.c:2997
Lisp_Object Ffuncall(
int nargs = 2,
Lisp_Object * args = &23873065
)
...
goto done;
case 1:
> val = (*XSUBR (fun)->function) (internal_args[0]);
goto done;
case 2:
...
0110C683 emacs.exe:0110C683 Fbyte_code bytecode.c:679
Lisp_Object Fbyte_code(
Lisp_Object bytestr = 18775699,
Lisp_Object vector = 18775716,
Lisp_Object maxdepth = 64
)
...
}
#endif
> TOP = Ffuncall (op + 1, &TOP);
AFTER_POTENTIAL_GC ();
break;
...
0100B997 emacs.exe:0100B997 funcall_lambda eval.c:3189
static Lisp_Object funcall_lambda(
Lisp_Object fun = ,
int nargs = 1,
Lisp_Object * arg_vector = &23779329
)
...
}
> return unbind_to (count, val);
}
...
0100BE8C emacs.exe:0100BE8C Ffuncall eval.c:3066
Lisp_Object Ffuncall(
int nargs = 2,
Lisp_Object * args = &26681993
)
...
done:
CHECK_CONS_LIST ();
> lisp_eval_depth--;
if (backtrace.debug_on_exit)
val = call_debugger (Fcons (Qexit, Fcons (val, Qnil)));
...
0110C683 emacs.exe:0110C683 Fbyte_code bytecode.c:679
Lisp_Object Fbyte_code(
Lisp_Object bytestr = 18776195,
Lisp_Object vector = 18776212,
Lisp_Object maxdepth = 32
)
...
}
#endif
> TOP = Ffuncall (op + 1, &TOP);
AFTER_POTENTIAL_GC ();
break;
...
0100B997 emacs.exe:0100B997 funcall_lambda eval.c:3189
static Lisp_Object funcall_lambda(
Lisp_Object fun = ,
int nargs = 1,
Lisp_Object * arg_vector = &23779329
)
...
}
> return unbind_to (count, val);
}
...
0100BE8C emacs.exe:0100BE8C Ffuncall eval.c:3066
Lisp_Object Ffuncall(
int nargs = 2,
Lisp_Object * args = &24273945
)
...
done:
CHECK_CONS_LIST ();
> lisp_eval_depth--;
if (backtrace.debug_on_exit)
val = call_debugger (Fcons (Qexit, Fcons (val, Qnil)));
...
0110B31E emacs.exe:0110B31E Fcall_interactively callint.c:862
Lisp_Object Fcall_interactively(
Lisp_Object function = 24273945,
Lisp_Object record_flag = 23779329,
Lisp_Object keys = 23842820
)
...
val = Ffuncall (count + 1, args);
UNGCPRO;
> return unbind_to (speccount, val);
}
}
...
0105591A emacs.exe:0105591A Fcommand_execute keyboard.c:10116
Lisp_Object Fcommand_execute(
Lisp_Object cmd = 24273945,
Lisp_Object record_flag = 23779329,
Lisp_Object keys = 23779329,
Lisp_Object special = 23779329
)
...
backtrace.debug_on_exit = 0;
> tem = Fcall_interactively (cmd, record_flag, keys);
backtrace_list = backtrace.next;
...
0105C6CA emacs.exe:0105C6CA command_loop_1 keyboard.c:1873
Lisp_Object command_loop_1(
)
...
if (NILP (current_kboard->Vprefix_arg))
Fundo_boundary ();
> Fcommand_execute (Vthis_command, Qnil, Qnil, Qnil);
#ifdef HAVE_X_WINDOWS
...
0100A2B7 emacs.exe:0100A2B7 internal_condition_case eval.c:1482
Lisp_Object internal_condition_case(
Lisp_Object ()(void) * bfun = &command_loop_1,
Lisp_Object handlers = 23847561,
Lisp_Object ()(void) * hfun = &cmd_error
)
...
val = (*bfun) ();
> catchlist = c.next;
handlerlist = h.next;
return val;
...
01050556 emacs.exe:01050556 command_loop_2 keyboard.c:1329
Lisp_Object command_loop_2(
)
...
do
> val = internal_condition_case (command_loop_1, Qerror, cmd_error);
while (!NILP (val));
...
0100A1EC emacs.exe:0100A1EC internal_catch eval.c:1222
Lisp_Object internal_catch(
Lisp_Object tag = 23837697,
Lisp_Object ()(void) * func = &command_loop_2,
Lisp_Object arg = 23779329
)
...
/* Call FUNC. */
if (! _setjmp (c.jmp))
> c.val = (*func) (arg);
/* Throw works by a longjmp that comes right here. */
...
010503A3 emacs.exe:010503A3 command_loop keyboard.c:1312
Lisp_Object command_loop(
)
...
/* End of file in -batch run causes exit here. */
> if (noninteractive)
Fkill_emacs (Qt);
}
...
01050437 emacs.exe:01050437 recursive_edit_1 keyboard.c:1007
Lisp_Object recursive_edit_1(
)
...
val = command_loop ();
> if (EQ (val, Qt))
Fsignal (Qquit, Qnil);
/* Handle throw from read_minibuf when using minibuffer
...
0105051C emacs.exe:0105051C Frecursive_edit keyboard.c:1068
Lisp_Object Frecursive_edit(
)
...
recursive_edit_1 ();
> return unbind_to (count, Qnil);
}
...
010029E8 emacs.exe:010029E8 main emacs.c:1765
int main(
int argc = 2,
char * * argv = &0x012be1b8
)
...
/* NOTREACHED */
return 0;
> }
/* Sort the args so we can find the most important ones
...
010011E7 emacs.exe:010011E7
01001238 emacs.exe:01001238
7C816D4F kernel32.dll:7C816D4F RegisterWaitForInputIdle
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Crash using text property 'composite on w32
2007-06-12 3:19 ` Eli Zaretskii
@ 2007-06-12 10:28 ` Lennart Borgman (gmail)
0 siblings, 0 replies; 11+ messages in thread
From: Lennart Borgman (gmail) @ 2007-06-12 10:28 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: lekktu, bug-gnu-emacs
Eli Zaretskii wrote:
>> Date: Tue, 12 Jun 2007 02:30:23 +0200
>> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
>> Cc: bug-gnu-emacs@gnu.org
>>
>> Juanma Barranquero wrote:
>>> 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
>> Ah, thanks. I am not familiar with gdb.
>
> You could also configure drmingw.exe (from mingw-utils-0.3.tar.gz) as
> your JIT debugger. This is what I get from it if I try your recipe:
Thanks Eli. I have not noticed there is such a thing as drmingw before.
For those interested in downloading: This file is on the MinGW download
page. Many of the other files should be downloaded from SourceForge. It
seems like no one has had the time and interest to clean up the MinGW
download page yet.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Crash using text property 'composite on w32
2007-06-12 0:07 ` Juanma Barranquero
2007-06-12 0:30 ` Lennart Borgman (gmail)
@ 2007-06-12 15:44 ` Chong Yidong
2007-06-14 12:32 ` Kenichi Handa
1 sibling, 1 reply; 11+ messages in thread
From: Chong Yidong @ 2007-06-12 15:44 UTC (permalink / raw)
To: bug-gnu-emacs; +Cc: Kenichi Handa
"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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Crash using text property 'composite on w32
2007-06-12 15:44 ` Chong Yidong
@ 2007-06-14 12:32 ` Kenichi Handa
2007-06-14 12:42 ` Lennart Borgman (gmail)
0 siblings, 1 reply; 11+ messages in thread
From: Kenichi Handa @ 2007-06-14 12:32 UTC (permalink / raw)
To: Chong Yidong; +Cc: emacs-devel
In article <87bqfl5g90.fsf@stupidchicken.com>, Chong Yidong <cyd@stupidchicken.com> writes:
> The following message is a courtesy copy of an article
> that has been posted to gmane.emacs.bugs as well.
> "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.
Thank you for finding this bug. You are right. I installed
a fix in the trunk. Anyway, composition property should not
be attached manually as this:
(let ((s "text"))
(put-text-property 0 2 'composition ?A s)
(insert s))
Instead, people should use compose-region or compose-string
as this:
(insert (compose-string "text" 0 2 ?A))
> 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?
Yes. The above description is for the argument COMPONENTS
of the function `compose-region', or for just a part of the
property value. The value has this form:
The property value has this form when the composition is made:
((LENGTH . COMPONENTS) . MODIFICATION-FUNC)
then turns to this form:
(COMPOSITION-ID . (LENGTH COMPONENTS-VEC . MODIFICATION-FUNC))
when the composition is registered in composition_hash_table and
composition_table. These rather peculiar structures were designed
to make it easy to distinguish them quickly (we can do that by
checking only the first element) and to extract LENGTH (from the
former form) and COMPOSITION-ID (from the latter form).
[...]
The detail is described in the header comment of
src/composite.c. How much detail, do you think, we should
describe in Info?
Isn't it enough to say just as below?
The value should be a cons of special structure. It should
be manipulated only by the functions `compose-region',
`compose-string' and `find-composition'.
---
Kenichi Handa
handa@m17n.org
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Crash using text property 'composite on w32
2007-06-14 12:32 ` Kenichi Handa
@ 2007-06-14 12:42 ` Lennart Borgman (gmail)
0 siblings, 0 replies; 11+ messages in thread
From: Lennart Borgman (gmail) @ 2007-06-14 12:42 UTC (permalink / raw)
To: Kenichi Handa; +Cc: Chong Yidong, emacs-devel
Kenichi Handa wrote:
> The value should be a cons of special structure. It should
> be manipulated only by the functions `compose-region',
> `compose-string' and `find-composition'.
If that is the case then I think the elisp manual should say that and
nothing else.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2007-06-14 12:42 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-06-11 16:32 Crash using text property 'composite on w32 Lennart Borgman (gmail)
2007-06-11 23:49 ` Jason Rumney
2007-06-11 23:58 ` Lennart Borgman (gmail)
2007-06-12 0:04 ` Jason Rumney
2007-06-12 0:07 ` Juanma Barranquero
2007-06-12 0:30 ` Lennart Borgman (gmail)
2007-06-12 3:19 ` Eli Zaretskii
2007-06-12 10:28 ` Lennart Borgman (gmail)
2007-06-12 15:44 ` Chong Yidong
2007-06-14 12:32 ` Kenichi Handa
2007-06-14 12:42 ` Lennart Borgman (gmail)
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.