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

Previous Next

Full log

Message #97 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: Wed, 09 Feb 2022 04:53:05 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> Neither do I, so there's something else at work here.

I failed to find a recipe in half an hour and gave up for now - instead
I found one for a very similar case of unexpected auto-scrolling that
only appears when the new feature is turned on.  Also seems to depend on
the buffer contents.  Maybe it is related and a fix fixes the other
thing, too.

emacs -Q
1 C-h i
2 move point to the beginning of one of the last visible lines.
  no scrolling happens (good).
3 M-: (setq make-window-start-visible t) RET  => *info* buffer scrolled

If you scroll back so that (point-min) becomes visible and repeat step
2 any activation of the minibuffer, e.g. just hitting M-: or C-x k,
scrolls the *info* buffer.

Doesn't happen in C-h n.  Dunno what makes the difference - the fact
that *info* is narrowed or that different fonts are used.

Ah - wait, now I can reproduce the other thing, too:

M-:
(progn
  (setq-default display-time-interval 1.)
  (setq display-time-format "%H:%M:%S")
  (setq-default make-window-start-visible t)
  (display-time-mode +1))
RET
C-h i
[down] [down] not too fast ... until it scrolls

I guess it's the same and just differs in when and how redisplay is
triggered.

Michael.

Previous Next

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