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

Previous Next

Full log

Message #70 received at 14582 <at> debbugs.gnu.org (full text, mbox):

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

Eli Zaretskii <eliz <at> 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.

Previous Next

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