bug#3020: 23.0.92; `previous-line' sometimes fails with overlays

[Stephen Berman]

On Thu, 16 Apr 2009 20:34:23 +0200 Markus Triska <markus.triska@gmx.at> wrote:

> When I evaluate the following form in "emacs -Q":
>
>    (progn
>      (switch-to-buffer (get-buffer-create "test"))
>      (insert "the first line\na ")
>      (let ((o (make-overlay (point) (point))))
>        (overlay-put
>         o 'after-string
>         (propertize (concat "very very very very very very very very "
>                             "very very very very very very very very "
>                             "long line") 'face '(:background "cyan"))))
>      (insert "\nand the last line")
>      (previous-line))
>
> and then press C-p, point unexpectedly fails to move. However, when I
> then press C-a C-n C-p C-p, the second C-p works as expected.

Here are some further observations:

- The first C-p does not fail when the propertized string is short
  enough so that when point is at the end of the string it is visually
  below but crucially before any initial segment of the string.  To see
  this with window-width of 85 (else adjust accordingly) replace the
  second string of the concat above by each of the following, evalling
  and trying C-p in between:
      "very very very very very very very "
      "very very very very very very very  "

- The first C-p does not fail when the propertized string is alone on
  the line it starts on, i.e., not preceded by another string on the
  same line.  To see this replace the first inserted string by each of
  the following, evalling and trying C-p in between:
      "the first line\n "
      "the first line\n"

- The condition under which the second C-p works is when point is at a
  lower column number than the column at which the propertized string
  begins.  For example, in the above the propertized string begins at
  column 2, and the second C-p works if point is at column 0 or column 1
  when the movement from below begins; if point is at column 2 or
  higher, the second C-p fails.

- The previous observation recalls a problem with the invisible text
  property I noted in the context of a different, but perhaps related,
  bug; see
  http://thread.gmane.org/gmane.emacs.pretest.bugs/2194/focus=83503

Steve Berman