GNU bug report logs - #43519
28.0.50; Overlay at end of minibuf hides minibuf's real content

Previous Next

Full log

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 43519 <at> debbugs.gnu.org
Subject: Re: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's
 real content
Date: Sun, 20 Sep 2020 18:40:15 -0400

>> That the redisplay performed horizontal scrolling when it was not needed
>> since the cursor was already visible without such scrolling.
> There's no horizontal scrolling.

To the extent that window-start is not at BOL, I think this qualifies as
horizontal scrolling, but maybe horizontal scrolling has a more specific
meaning within the redisplay with which I'm not aware.

> The issue is with determining the
> mini-window's start position.  In the case with the overlay, we
> compute that position as EOB, whereas in the case with buffer text, we
> compute it to be at BOB.  The reason is what I said: the very
> different behavior of the move_it_* functions when they need to
> traverse overlay strings.
>
> The basic logic of resize_mini_window is like this:
>
>   . compute the number of screen lines required for displaying the
>     mini-window
>   . if the computed number of screen lines is more than
>     max-mini-window-height allows, then compute where to start the
>     mini-window display, as follows:
>     - start at the end of the stuff to be displayed in the mini-window
>     - move back max-mini-window-height screen lines
>     - use the start of the screen line where we wind up as the
>       mini-window's start point

Hmm...  I think I'm beginning to see where the difficulty might be
coming from, but it's still quite fuzzy.  In my mind I'd have expected
the code to work more along the lines of:

    - compute the number of screen lines required for displaying the
      mini-window
    - enlarge/shrink the window accordingly
    - rely on the usual redisplay code for the rest (which may decide to
      change window-start in order to keep point within view, but in
      our current example(s) wouldn't need to do that).

Do you know why we don't do it this way, IOW why don't we first try to
keep window-start unchanged and see if point ends up within view?

>> So the question is: how to get the same behavior as what we'd get with
>> `insert` but without actually modifying the buffer's contents?
> You can't, not without redesigning the display code.  At least not in
> the general way you describe the issue, and not to the best of my
> knowledge.

IIUC the problem only shows up because of the auto-resizing of the
minibuffer window, right?
Indeed if I replace

    (setq max-mini-window-height 1)
with
    (setq resize-mini-windows nil)

the problem doesn't appear, even though resizing is in fact disabled in
both cases.


        Stefan

Previous Next

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