bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> I installed a change along these lines.  A buffer that sets the new
> variable make-window-start-visible non-nil should force redisplay to
> reject a window-start point that is in invisible text or is covered by
> a "replacing" 'display' property (which also makes window-start
> invisible), and choose a different starting point.
>
> Please test.

Cool - thanks.

I played shortly with the new option enabled.  I didn't experience this
issue, but in some situations redisplay seems to infloop.  Seems that
happens when the first line is wrapped - at least I didn't see the same
problem without wrapped lines.  Here is a reproducer for emacs -Q (just
eval with M-:):

#+begin_src emacs-lisp
(progn
  (dotimes (_ 100) (insert "\
\(defun foooooooooo (long-arg another-long-arg an-even-very-long-arg \
and-one-more-arg)
  1
  2)\n"))
  (setq make-window-start-visible t)
  (goto-char (point-max))
  (sit-for 1)
  (scroll-down)
  (sit-for 1)
  (hs-minor-mode)
  (hs-hide-all))
#+end_src

BTW, I wondered - do we also have to care about window-end - or can
the thing this report is about only happen for window-start?

Thanks,

Michael.