emacs-pretest-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Display problems with 'before-string in overlay


From: Chong Yidong
Subject: Re: Display problems with 'before-string in overlay
Date: Thu, 12 Apr 2007 14:55:13 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.97 (gnu/linux)

address@hidden (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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]