Hello, Angus:
I have made some interesting observations regarding to the "swallowing"
of the first CJK-chars on the "Edit->Find&Search" box.
The 'draw_char' in input.c starts with the block,
"if (sp->endrange >= 0)
{
delete_piece(ob, sp->beginrange, sp->endrange - 1);
slen = strlen(sp->str);
}"
and 'delete_piece(...)' is defined as
"static void
delete_piece(FL_OBJECT * ob, register int start, register int end)
{
register SPEC *sp = ob->spec;
register int i = 0;
do
{
i++;
sp->str[start + i - 1] = sp->str[end + i];
}
while (sp->str[end + i] != '\0');
sp->position = start;
sp->lines = fl_get_input_numberoflines(ob);
fl_get_input_cursorpos(ob, &sp->xpos, &sp->ypos);
}"
The first interesting fact is that no signal from the keyboard enters the
first block of 'draw_char' EXCEPT it is the first input from the keyboard
to "Edit->Find..." widget. I mean No signal enters this block(whether it
is the first one or not) when we are on any other xforms widget.
When closely looking at it on "Edit->Find..." widget, I found that one
signal enters the block when the first key is English character such as
'a' or 'A' or 'space', etc, while two signals enter successively the block
when the first key is the precomposed one CJK-char. In the latter
case(CJK-char case) the 'space' signal bypasses the block.
The second interesting fact is that unknowing why
'sp->position = start;' line in 'delete_piece(....)' is there, I removed
that line, and "Bang" the 'swallowing" problem went away. I found no
problem with this hack so far. Can you justify this hack, or give
me any other idea?
Regards,
cghan
P.S. I am waiting for your comments or suggestion regarding the
xfoms-1.0-i18n.patch I sent you yesterday.
