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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: larsi <at> gnus.org, esabof <at> gmail.com, 14582 <at> debbugs.gnu.org
Subject: bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.
Date: Fri, 04 Feb 2022 15:56:29 +0200

> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Cc: larsi <at> gnus.org,  esabof <at> gmail.com,  14582 <at> debbugs.gnu.org
> Date: Fri, 04 Feb 2022 02:37:44 +0100
> 
> 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

Thanks, should be fixed now.

> 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?

window-end point is determined as side effect of successful complete
redisplay of a window, and cannot be determined before redisplay is
complete.  The window-end point isn't necessarily at the end of some
physical line, and it is by definition at the end of a visual line.
So I don't see why would we need to care about something similar
happening at the window's end.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.