GNU bug report logs -
#11199
24.0.95; killing right-to-left text at eob leads to inconsistent state
Previous Next
Full log
View this message in rfc822 format
>>>>> On Mon, 09 Apr 2012 12:10:09 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
> I cannot figure out where these two numbers, 309 and 313, come from.
> If I repeat the recipe and look at the glyph matrix _before_ C-k,
> there are no such buffer positions anywhere in sight there.
I guess this just comes from some white space difference introduced by
copy-and-paste.
> Also, please verify that you see the same buffer positions in the
> glyph matrix as I do. Here's a GDB session I used to this end:
I get the same results on Mac OS X 10.7.3, X11 build.
> (gdb) pmtxrows w->current_matrix
> 0: edges=(1,78),r2l=0,cont=0,trunc=(0,0),at_zv=0
> 1: edges=(78,141),r2l=0,cont=0,trunc=(0,0),at_zv=0
> 2: edges=(141,191),r2l=0,cont=0,trunc=(0,0),at_zv=0
> 3: edges=(191,192),r2l=0,cont=0,trunc=(0,0),at_zv=0
> 4: edges=(192,199),r2l=0,cont=0,trunc=(0,0),at_zv=0
> 5: edges=(199,237),r2l=0,cont=0,trunc=(0,0),at_zv=0
> 6: edges=(237,305),r2l=0,cont=0,trunc=(0,0),at_zv=0
> 7: edges=(305,309),r2l=0,cont=0,trunc=(0,0),at_zv=1
(snip)
What is shown by
(gdb) p w->current_matrix->rows[6].end.pos
at this stage? I get
$7 = {
charpos = 308,
bytepos = 311
}
and it looks "out of sync" because edges=(237,305) for the 6th row.
I hope this is also reproducible at your side.
YAMAMOTO Mitsuharu
mituharu <at> math.s.chiba-u.ac.jp
This bug report was last modified 13 years and 40 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.