Re: xdisp.c problem?

[Tak Ota]

Thu, 30 Jan 2003 12:51:03 +0900 (JST): Kenichi Handa <address@hidden> wrote:

> In article <address@hidden>, Tak Ota <address@hidden> writes:
> >>  > 2003-01-29  Kenichi Handa  <address@hidden>
> >>  >         * xdisp.c (set_cursor_from_row): Pay attention to string display
> >>  >         properties.
> >>  
> >>  > This change causes emacs to get hung when I try to view a message of
> >>  > the following type.  Switching back to the old xdisp.c eliminates the
> >>  > problem.
> >>  
> >>  > Content-Type: text/html; charset="euc-kr"
> >>  
> >>  Could you show me exactly what to do to reproduce that bug?
> 
> > I tried to isolate the case from the entire circumstance, which is
> > using Mew package to view email messages.  I was not successful.  It
> > happens only when I try to view certain messages.  C-g does not break
> > emacs once it gets trapped in this situation.  There is one more fact
> > I have gained by tracing elisp execution.  The last lisp function
> > called is `overlay-put' and the emacs stops responding after that.  I
> > used C debugger to follow the trace from entry to `overlay-put' but
> > could not conclusion anything meaningful.
> 
> Please check if Emacs is in an infinite loop or not, and if
> it's in an infinite loop, find in which part of code it's
> executing.

I'll try it later.  While I played with the problem a bit more
yesterday I narrowed it to the following action.

(overlay-put
 (make-overlay (point-max) (point-max))
 'before-string
 "[End of message]")

The difficulty to reproduce this for you is that it is buffer content
dependent.  If I save the buffer to a file the text properties are
gone.  I don't know if text properties are relevant to this problem
but saving the buffer to a file and revisiting it and performing above
action does not produce the problem anymore.  Is there a way to save
the complete buffer information to a file including text properties?

> It's not likely that the modified function
> set_cursor_from_row itself has an infinite loop, but it may
> set cursor position to where the other display engine code
> don't expect.

I agree with your insight.

-Tak