[EMAIL PROTECTED] (Kim F. Storm) writes: > IIRC, the original problem I tried to solve is shown by this test-case: > > (progn > (switch-to-buffer (get-buffer-create "*test*")) > (erase-buffer) > (insert ".\n<\n.\n>\n") > (goto-char (point-min)) > (let ((ov (make-overlay 4 7))) > (overlay-put ov 'display "Ax\nyB")) > (goto-char (point-max))) > > With my change, moving the cursor places it on the 'A'. > Without my change, moving the cursor places it on the 'y'. > So my change may be incorrect - but it _does_ solve a real problem.
OK, now I see the problem. I believe the underlying fault is not in cursor_row_p, but in set_cursor_from_row, on xdisp.c:11948: pos = string_buffer_position (w, string, string_before_pos); /* If STRING is from overlay, LAST_POS == 0. We skip such glyphs because we always put cursor after overlay strings. */ while (pos == 0 && glyph < stop) { string = glyph->object; The assumption made in the comment is not correct: string_buffer_position returns non-zero values for overlay strings with the `display' property. In xdisp.c:4446: prop = Fget_char_property (pos, Qdisplay, Qnil); if (!NILP (prop) && display_prop_string_p (prop, string)) found = 1; This suggests that the way to fix this is to change string_buffer_position to do what that says. However, it is dangerous to change string_buffer_position right now, because it's called from several places in xdisp.c. Changing its behavior runs a serious risk of introducing subtle bugs. Thus, I think this issue should be left alone for the Emacs 22.1. It is easy to work around the affected corner case, by using text properties or a display property rather an overlay with a before-string. After 22.1, I can take a look at fixing this along the lines discussed above. _______________________________________________ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug