Re: composition bug

[Kenichi Handa <handa@m17n.org>]

In article <87prn457u2.fsf@elegiac.orebokech.com>, Romain Francoise <romain@orebokech.com> writes:

> Kenichi Handa <handa@m17n.org> writes:
> > Hmmm, it seems that there's a pattern.  What does this
> > return when the point is 1, 256, 414:

> >   ESC : (find-composition (point) (point-max) RET

> (255 256 [[#<font-object "-mutt-clearlyu-medium-r-normal--17-120-100-100-p-123-iso10646-1"> 1617] 0 [0 0 1617 1617 0 1 6 15 -12 [0 0 6]]])

> (412 414 [[#<font-object "-mutt-clearlyu-medium-r-normal--17-120-100-100-p-123-iso10646-1"> 3732 3765] 1 [0 1 3732 3732 8 1 8 9 0 nil] [0 1 3765 3765 0 -7 2 13 -10 nil]])

> (419 420 [[#<font-object "-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1"> 8205] 2 [0 0 8205 8205 6 0 0 0 0 [0 0 6]]])


Ok, so, C-n at the beginning of HELLO moves the point to the
end of first composition, and the 2nd C-n moves the point to
the end of 2nd composition.  But, the 3rd C-n doesn't
follows that pattern.

Please run Emacs under gdb as below:
          
M-x gdb RET /usr/local/work/emacs/src/emacs RET
            |-----------------------------|-> please adjust for your case
(gdb) br composite.c:1432
(gdb) run -Q

Then visit HELLO file by the Emacs running under gdb, and
type C-n.  Emacs should stop at the break point.  Then,
please find why the point moves to 256 by running the code
one line by line.

---
Kenichi Handa
handa@ni.aist.go.jp