Mike Kupfer writes:
> If you cast addresses to Lisp_Object, you can often get sense
out of
> them with pobj.
What's pobj?
You don't know about pobj? You're going to love it, then! You need
to source src/.gdbinit in the XEmacs tree to get it defined. pobj on
a Lisp_Object will decode it, telling you what type it is and tracking
down all the parts.
On second thought this probably doesn't work well with display
structures or Dynarrs, though. They mostly are not going to have
Lisp_Objects in them.
variables for pixel_to_glyph_translation(). If I got it right,
&db is
0xbfc176d8 and *db is
(gdb) print {struct display_block}0x0a8b03a0
$23 = {type = TEXT, start_pos = 4, end_pos = 4, runes = 0xa7c3148}
HTH.
Oh, it does. (If correct -- I'm a little worried because I don't
understand why start_pos == 4 here.) Since it's type == TEXT, it very
well could be the minibuffer with no displayable text in it. While
typeahead shouldn't have the effect of moving pointers past array
bounds, as your analysis shows if redisplay gets triggered on a line
with no runes in it, that can happen here.
It's possible that this doesn't happen except on redisplay of last
line in a buffer without an EOL. Then this would be very unlikely
... except for typeahead in the minibuffer, where the focus is almost
always on a line without an EOL. (Why does EOL matter? Because it is
treated as a pseudo-glyph. Grep for "cheesy" in the redisplay code. :-)
Heh. If I get to the point where I understand the code enough, I
will.
Heck even good questions wouldn't hurt. Ben will often answer them in
his next megapatch. :-)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta