[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
