GNU logs - #43519, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 19 Sep 2020 17:55:02 +0000
Resent-Message-ID: <handler.43519.B.16005380729680 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 43519 <at> debbugs.gnu.org
From: Stefan Monnier <monnier@HIDDEN>
Date: Sat, 19 Sep 2020 13:54:13 -0400
Message-ID: <jwvft7dveii.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
Received-SPF: pass client-ip=132.204.25.50;
 envelope-from=monnier@HIDDEN; helo=mailscanner.iro.umontreal.ca
X-Spam_score_int: -42
X-Spam_score: -4.3
X-Spam_bar: ----
X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

Package: Emacs
Version: 28.0.50


    % src/emacs -Q --eval '(setq max-mini-window-height 1)' -f icomplete-mode
    M-x a

at this point, you should presumably not see the "M-x a" in your
minibuffer window but only something of the form "{rp | lign | ..."

This is probably related to bug#24293 and bug#39379.


        Stefan

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Stefan Monnier <monnier@HIDDEN>
Subject: bug#43519: Acknowledgement (28.0.50; Overlay at end of minibuf
 hides minibuf's real content)
Message-ID: <handler.43519.B.16005380729680.ack <at> debbugs.gnu.org>
References: <jwvft7dveii.fsf@HIDDEN>
X-Gnu-PR-Message: ack 43519
X-Gnu-PR-Package: emacs
Reply-To: 43519 <at> debbugs.gnu.org
Date: Sat, 19 Sep 2020 17:55:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 43519 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
43519: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D43519
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 19 Sep 2020 18:53:01 +0000
Resent-Message-ID: <handler.43519.B43519.160054153723302 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Stefan Monnier <monnier@HIDDEN>
Cc: 43519 <at> debbugs.gnu.org
Date: Sat, 19 Sep 2020 21:52:04 +0300
Message-Id: <83wo0p1twr.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <jwvft7dveii.fsf@HIDDEN> (message from Stefan Monnier
 on Sat, 19 Sep 2020 13:54:13 -0400)
References: <jwvft7dveii.fsf@HIDDEN>
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> From: Stefan Monnier <monnier@HIDDEN>
> Date: Sat, 19 Sep 2020 13:54:13 -0400
> 
>     % src/emacs -Q --eval '(setq max-mini-window-height 1)' -f icomplete-mode
>     M-x a
> 
> at this point, you should presumably not see the "M-x a" in your
> minibuffer window but only something of the form "{rp | lign | ..."

Seems like a bug in icomplete: it attempts to compute the maximum
length of candidates to be displayed, but seems like it fails, because
the single mini-window line is continued, with no ellipsis at the end
of the visible line?

The fact that it calls window-width with no arguments is one possible
problem -- it assumes the default face's font.  But I think the
problem is more prominent than just that.

It should produce an overlay string that fits in the window, then the
prompt will be visible.

Am I missing something?

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 19 Sep 2020 19:43:02 +0000
Resent-Message-ID: <handler.43519.B43519.160054454327852 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 43519 <at> debbugs.gnu.org
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwvh7rta7et.fsf-monnier+emacs@HIDDEN>
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
Date: Sat, 19 Sep 2020 15:42:12 -0400
In-Reply-To: <83wo0p1twr.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 19 Sep
 2020 21:52:04 +0300")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

>> From: Stefan Monnier <monnier@HIDDEN>
>> Date: Sat, 19 Sep 2020 13:54:13 -0400
>> 
>>     % src/emacs -Q --eval '(setq max-mini-window-height 1)' -f icomplete-mode
>>     M-x a
>> 
>> at this point, you should presumably not see the "M-x a" in your
>> minibuffer window but only something of the form "{rp | lign | ..."
>
> Seems like a bug in icomplete: it attempts to compute the maximum
> length of candidates to be displayed, but seems like it fails, because
> the single mini-window line is continued, with no ellipsis at the end
> of the visible line?

I disagree: icomplete merely added text after point via an overlay and
didn't do anything which explicitly justifies horizontal scrolling.

I suspect the problem is that point is right on the overlay, so in
a sense it's both before *and* after the "{...}" text.  Conceptually it
should be considered as being before (which is why the cursor is placed
on the `{`), and the redisplay somewhat agrees with it (because it
hides the end of "{...}" rather than its beginning) but not completely
since it scrolled the display even though the `{` was already visible
without it.

> The fact that it calls window-width with no arguments is one possible
> problem -- it assumes the default face's font.  But I think the
> problem is more prominent than just that.
>
> It should produce an overlay string that fits in the window, then the
> prompt will be visible.

That would merely work around the underlying problem (and as you know
it's wickedly difficult to construct a string which will have "just the
right size" to fit into the minibuffer window).

Maybe there's a good reason for the redisplay to behave this way, but if
that's the case we need some way for icomplete (and other similar cases)
to make it behave differently.

        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 19 Sep 2020 20:11:01 +0000
Resent-Message-ID: <handler.43519.B43519.160054625130429 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.160054625130429
          (code B ref 43519); Sat, 19 Sep 2020 20:11:01 +0000
Received: (at 43519) by debbugs.gnu.org; 19 Sep 2020 20:10:51 +0000
Received: from localhost ([127.0.0.1]:48176 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kJjC7-0007ui-IW
	for submit <at> debbugs.gnu.org; Sat, 19 Sep 2020 16:10:51 -0400
Received: from eggs.gnu.org ([209.51.188.92]:59036)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1kJjC6-0007uV-Il
 for 43519 <at> debbugs.gnu.org; Sat, 19 Sep 2020 16:10:51 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:51430)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1kJjBz-0002XE-D3; Sat, 19 Sep 2020 16:10:44 -0400
Received: from [176.228.60.248] (port=3485 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1kJjBu-0000oe-Pf; Sat, 19 Sep 2020 16:10:42 -0400
Date: Sat, 19 Sep 2020 23:10:36 +0300
Message-Id: <83r1qx1q9v.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> (message from Stefan
 Monnier on Sat, 19 Sep 2020 15:42:12 -0400)
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: 43519 <at> debbugs.gnu.org
> Date: Sat, 19 Sep 2020 15:42:12 -0400
> 
> > Seems like a bug in icomplete: it attempts to compute the maximum
> > length of candidates to be displayed, but seems like it fails, because
> > the single mini-window line is continued, with no ellipsis at the end
> > of the visible line?
> 
> I disagree: icomplete merely added text after point via an overlay and
> didn't do anything which explicitly justifies horizontal scrolling.

Maybe I'm missing something, but what does the code in
icomplete-completions that calls string-width and window-width try to
do, then?  I mean this part:

	     ;;"-prospects" - more than one candidate
	     (prospects-len (+ (string-width
				(or determ (concat open-bracket close-bracket)))
			       (string-width icomplete-separator)
			       (+ 2 (string-width ellipsis)) ;; take {…} into account
			       (string-width (buffer-string))))
             (prospects-max
              ;; Max total length to use, including the minibuffer content.
              (* (+ icomplete-prospects-height
                    ;; If the minibuffer content already uses up more than
                    ;; one line, increase the allowable space accordingly.
                    (/ prospects-len (window-width)))
                 (window-width)))

> I suspect the problem is that point is right on the overlay, so in
> a sense it's both before *and* after the "{...}" text.

The point is at EOB, and we have an overlay string there.  The overlay
string has a 'cursor' property on its first character, so the display
engine puts the cursor there.  Without that, we'd have the cursor at
the end of the overlay string, thus showing something even less
reasonable.

But I'm not sure how this is related to the issue at hand.

> > It should produce an overlay string that fits in the window, then the
> > prompt will be visible.
> 
> That would merely work around the underlying problem

What do you think is the underlying problem?

> (and as you know it's wickedly difficult to construct a string which
> will have "just the right size" to fit into the minibuffer window).

It doesn't have to be "just the right size", it could err on the safe
side.  It already attempts to do so, by avoiding truncation in the
middle of a candidate.  It should just do a better job, that's all.

> Maybe there's a good reason for the redisplay to behave this way

Behave in what way? what's special about what you see on display in
this case, given the contents of the mini-window's buffer?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 19 Sep 2020 22:07:01 +0000
Resent-Message-ID: <handler.43519.B43519.16005531929583 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.16005531929583
          (code B ref 43519); Sat, 19 Sep 2020 22:07:01 +0000
Received: (at 43519) by debbugs.gnu.org; 19 Sep 2020 22:06:32 +0000
Received: from localhost ([127.0.0.1]:48332 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kJl03-0002UV-U1
	for submit <at> debbugs.gnu.org; Sat, 19 Sep 2020 18:06:32 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:50182)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1kJl00-0002UF-Fq
 for 43519 <at> debbugs.gnu.org; Sat, 19 Sep 2020 18:06:30 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 4833A10022D;
 Sat, 19 Sep 2020 18:06:23 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 8A09A10022A;
 Sat, 19 Sep 2020 18:06:21 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1600553181;
 bh=q8ecgnt4qG77aa+EPf8gnzVcSCSb27gOYiVGu2T3Xlc=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=FbwmSe5xLub3OjQzGpFN8fUjrW4ENxdVpmqKINPpBrx0kKEjSy72HDDH3Z/bCfyaB
 ojEk8sx2ue8xkvn7EWbYG8DNxEo+DBLFt5fHP/Of+0Wu14vVH7CirZAndGsdYWOBSa
 ZtQOcUATngJpcdtB1YvmtQEyePnciwy1zsnQVxrRPdsXbTpbMy/3YvIE1D6AZTcE8C
 liZq8A0Nl1Vf2QtivtJayWTAlHTl6BF/Z7nXDUxjpj5VL8whZaSZIP58RMVQg7nzon
 BGh0YbKO8pTr/ficMq5C5J3zLWGqapUPQwkZHm5LaoCC4sC5OEMg4C3VJ4Xpb/8STn
 paBNurK6zIcDQ==
Received: from alfajor (unknown [45.72.232.131])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 4CB241202E9;
 Sat, 19 Sep 2020 18:06:21 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwvzh5l8med.fsf-monnier+emacs@HIDDEN>
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
Date: Sat, 19 Sep 2020 18:06:20 -0400
In-Reply-To: <83r1qx1q9v.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 19 Sep
 2020 23:10:36 +0300")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.050 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> I disagree: icomplete merely added text after point via an overlay and
>> didn't do anything which explicitly justifies horizontal scrolling.
>
> Maybe I'm missing something, but what does the code in
> icomplete-completions that calls string-width and window-width try to
> do, then?  I mean this part:
>
> 	     ;;"-prospects" - more than one candidate
> 	     (prospects-len (+ (string-width
> 				(or determ (concat open-bracket close-bracket)))
> 			       (string-width icomplete-separator)
> 			       (+ 2 (string-width ellipsis)) ;; take {=E2=80=A6} into account
> 			       (string-width (buffer-string))))
>              (prospects-max
>               ;; Max total length to use, including the minibuffer conten=
t.
>               (* (+ icomplete-prospects-height
>                     ;; If the minibuffer content already uses up more than
>                     ;; one line, increase the allowable space accordingly.
>                     (/ prospects-len (window-width)))
>                  (window-width)))

That's not relevant to the issue at hand.  I used `icomplete-mode` only
as a vehicle to show the underlying behavior with a short recipe which
exhibits a real-life problem.

>> > It should produce an overlay string that fits in the window, then the
>> > prompt will be visible.
>> That would merely work around the underlying problem
> What do you think is the underlying problem?

That the redisplay performed horizontal scrolling when it was not needed
since the cursor was already visible without such scrolling.

>> (and as you know it's wickedly difficult to construct a string which
>> will have "just the right size" to fit into the minibuffer window).
> It doesn't have to be "just the right size", it could err on the safe
> side.  It already attempts to do so, by avoiding truncation in the
> middle of a candidate.  It should just do a better job, that's all.

And how do we generalize that to the case where the overlay contains
newlines, TABs, chars in different scripts using different fonts,
different faces, images, etc.... ?

>> Maybe there's a good reason for the redisplay to behave this way
> Behave in what way? what's special about what you see on display in
> this case, given the contents of the mini-window's buffer?

Try the recipe below instead:

    (minibuffer-with-setup-hook
        (lambda ()
          (insert "hello")
          (let ((ol (make-overlay (point) (point)))
                (max-mini-window-height 1)
                (text "askdjfhaklsjdfhlkasjdfhklasdhflkasdhflkajsdhflkashdf=
kljahsdlfkjahsdlfkjhasldkfhalskdjfhalskdfhlaksdhfklasdhflkasdhflkasdhflkajs=
dhklajsdgh"))
            (save-excursion (insert text))
            (sit-for 2)
            (delete-region (point) (point-max))
            (put-text-property 0 1 'cursor t text)
            (overlay-put ol 'after-string text)
            (sit-for 2)
            (delete-overlay ol)))
      (read-string "toto: "))

This performs "display of text after point" in 2 different ways:
- first by `insert`.
- then with an overlay.
The visual rendering of the text is the same, with the cursor at the
same place.  When we do it with `insert` there is no horizontal
scrolling, but when we do it with an overlay the text gets scrolled so
the cursor is at `window-start`.

`icomplete` needs the behavior to be the same as with `insert`, but it
prefers to use an overlay to avoid some undesirable side-effects of
modifying the actual text.

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?

Is it more clear now?


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: (no subject)
References: <jwvft7dveii.fsf@HIDDEN>
In-Reply-To: <jwvft7dveii.fsf@HIDDEN>
Resent-From: Gregory Heytings <ghe@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 20 Sep 2020 01:02:02 +0000
Resent-Message-ID: <handler.43519.B43519.160056366326571 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.160056366326571
          (code B ref 43519); Sun, 20 Sep 2020 01:02:02 +0000
Received: (at 43519) by debbugs.gnu.org; 20 Sep 2020 01:01:03 +0000
Received: from localhost ([127.0.0.1]:48440 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kJnix-0006uV-71
	for submit <at> debbugs.gnu.org; Sat, 19 Sep 2020 21:01:03 -0400
Received: from mx.sdf.org ([205.166.94.24]:57854)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ghe@HIDDEN>) id 1kJniu-0006tt-ME
 for 43519 <at> debbugs.gnu.org; Sat, 19 Sep 2020 21:01:01 -0400
Received: from sdf.org (IDENT:ghe@HIDDEN [205.166.94.9])
 by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 08K10v1q024459
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO);
 Sun, 20 Sep 2020 01:00:57 GMT
Received: (from ghe@localhost)
 by sdf.org (8.15.2/8.12.8/Submit) id 08K11BsT005837;
 Sun, 20 Sep 2020 01:01:11 GMT
Date: Sun, 20 Sep 2020 01:00:54 +0000
From: Gregory Heytings <ghe@HIDDEN>
Message-ID: <alpine.NEB.2.22.394.2009200241270453.27687@HIDDEN>
User-Agent: Alpine 2.22 (NEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
X-Spam-Score: 2.0 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  A short note, which could perhaps be useful: this behavior
 does not only happen when the overlay text is too wide for the minibuffer
 width (in which case it perhaps could be argued that the display en [...]
 Content analysis details:   (2.0 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_PASS               SPF: sender matches SPF record
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 1.8 MISSING_SUBJECT        Missing Subject: header
 0.2 NO_SUBJECT             Extra score for no subject
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)


A short note, which could perhaps be useful: this behavior does not only 
happen when the overlay text is too wide for the minibuffer width (in 
which case it perhaps could be argued that the display engine tries to do 
something appropriate).

For example, with (setq icomplete-separator "\n"), after M-x a the 
contents of the minibuffer is displayed as follows:

{rp
lign
propos
sm-mode
<... other candidates, one on each line>

After pressing C-b (or <left>), the prompt becomes visible, and the 
minibuffer is displayed as follows:

M-x a{rp
lign
propos
sm-mode
<... other candidates, one one each line>

(Note that the display position of the candidates is not modified, it is 
still aligned to the left border of the window, except for the first one.)

Pressing C-f (or <right>) returns to the initial display, the prompt 
becomes invisible again.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: (no subject)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 20 Sep 2020 06:10:01 +0000
Resent-Message-ID: <handler.43519.B43519.160058214322911 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Gregory Heytings <ghe@HIDDEN>
Cc: 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.160058214322911
          (code B ref 43519); Sun, 20 Sep 2020 06:10:01 +0000
Received: (at 43519) by debbugs.gnu.org; 20 Sep 2020 06:09:03 +0000
Received: from localhost ([127.0.0.1]:48567 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kJsX1-0005xT-GG
	for submit <at> debbugs.gnu.org; Sun, 20 Sep 2020 02:09:03 -0400
Received: from eggs.gnu.org ([209.51.188.92]:49230)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1kJsX0-0005x0-0U
 for 43519 <at> debbugs.gnu.org; Sun, 20 Sep 2020 02:09:03 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:59222)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1kJsWs-0007NT-BA; Sun, 20 Sep 2020 02:08:54 -0400
Received: from [176.228.60.248] (port=4188 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1kJsWr-0003gk-Me; Sun, 20 Sep 2020 02:08:54 -0400
Date: Sun, 20 Sep 2020 09:08:52 +0300
Message-Id: <83h7rt0ykr.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <alpine.NEB.2.22.394.2009200241270453.27687@HIDDEN>
 (bug-gnu-emacs@HIDDEN)
References: <jwvft7dveii.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009200241270453.27687@HIDDEN>
X-Spam-Score: -0.3 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.3 (-)

> Date: Sun, 20 Sep 2020 01:00:54 +0000
> From: Gregory Heytings via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
> 
> A short note, which could perhaps be useful: this behavior does not only 
> happen when the overlay text is too wide for the minibuffer width (in 
> which case it perhaps could be argued that the display engine tries to do 
> something appropriate).
> 
> For example, with (setq icomplete-separator "\n"), after M-x a the 
> contents of the minibuffer is displayed as follows:
> 
> {rp
> lign
> propos
> sm-mode
> <... other candidates, one on each line>

Does the entire list of candidates fit in the (enlarged) mini-window
in that case? or are some of the candidates not displayed due to lack
of space?

> After pressing C-b (or <left>), the prompt becomes visible, and the 
> minibuffer is displayed as follows:

C-b moves point from EOB to a character before EOB, thus the
difference (AFAIR).

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
References: <jwvft7dveii.fsf@HIDDEN>
In-Reply-To: <jwvft7dveii.fsf@HIDDEN>
Resent-From: Gregory Heytings <ghe@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 20 Sep 2020 08:29:01 +0000
Resent-Message-ID: <handler.43519.B43519.16005904833382 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.16005904833382
          (code B ref 43519); Sun, 20 Sep 2020 08:29:01 +0000
Received: (at 43519) by debbugs.gnu.org; 20 Sep 2020 08:28:03 +0000
Received: from localhost ([127.0.0.1]:48633 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kJuhX-0000sU-AP
	for submit <at> debbugs.gnu.org; Sun, 20 Sep 2020 04:28:03 -0400
Received: from mx.sdf.org ([205.166.94.24]:63659)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ghe@HIDDEN>) id 1kJuhT-0000s2-Ez
 for 43519 <at> debbugs.gnu.org; Sun, 20 Sep 2020 04:28:02 -0400
Received: from sdf.org (IDENT:ghe@HIDDEN [205.166.94.9])
 by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 08K8RwBB028122
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO);
 Sun, 20 Sep 2020 08:27:58 GMT
Received: (from ghe@localhost)
 by sdf.org (8.15.2/8.12.8/Submit) id 08K8SBFJ022748;
 Sun, 20 Sep 2020 08:28:11 GMT
Date: Sun, 20 Sep 2020 08:27:55 +0000
From: Gregory Heytings <ghe@HIDDEN>
Message-ID: <alpine.NEB.2.22.394.2009201009030453.20544@HIDDEN>
User-Agent: Alpine 2.22 (NEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


>> For example, with (setq icomplete-separator "\n"), after M-x a the 
>> contents of the minibuffer is displayed as follows:
>>
>> {rp
>> lign
>> propos
>> sm-mode
>> <... other candidates, one on each line>
>
> Does the entire list of candidates fit in the (enlarged) mini-window in 
> that case? or are some of the candidates not displayed due to lack of 
> space?
>

The list of candidates is in this case (with emacs -Q) 32 lines long 
("{rp" on the first line, ... "...}" on the last line).  With (setq 
max-mini-window-height 32) the M-x prompt is displayed, with (setq 
max-mini-window-height 31) it isn't.

But the point is that there is clearly enough horizontal space, so there 
is (or there does not seem to be) no reason to scroll horizontally.

>> After pressing C-b (or <left>), the prompt becomes visible, and the 
>> minibuffer is displayed as follows:
>
> C-b moves point from EOB to a character before EOB, thus the difference 
> (AFAIR).
>

Yes, I know what C-b does, what I find surprising (but perhaps it is not, 
I'm not an expert) is that only one line (the one with the prompt) is 
scrolled horizontally.

[taken from emacs-devel:]
>
> You are asking the display engine to do the impossible.
>

No.  With a minibuffer-only frame, the bug is not present.  Whatever the 
value of icomplete-separator (that is, with either a horizontal or 
vertical list of candidates), you do see the "M-x" prompt and the 
characters typed so far, even with (setq max-mini-window-height 1) and a 
one line minibuffer.  So it's feasible, and the display engine knows how 
to do it.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 20 Sep 2020 08:53:02 +0000
Resent-Message-ID: <handler.43519.B43519.160059193914016 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.160059193914016
          (code B ref 43519); Sun, 20 Sep 2020 08:53:02 +0000
Received: (at 43519) by debbugs.gnu.org; 20 Sep 2020 08:52:19 +0000
Received: from localhost ([127.0.0.1]:48677 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kJv51-0003e0-4O
	for submit <at> debbugs.gnu.org; Sun, 20 Sep 2020 04:52:19 -0400
Received: from eggs.gnu.org ([209.51.188.92]:44202)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1kJv4y-0003dm-Ud
 for 43519 <at> debbugs.gnu.org; Sun, 20 Sep 2020 04:52:18 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:60532)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1kJv4t-00077y-F8; Sun, 20 Sep 2020 04:52:11 -0400
Received: from [176.228.60.248] (port=2207 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1kJv4s-00086e-O5; Sun, 20 Sep 2020 04:52:11 -0400
Date: Sun, 20 Sep 2020 11:52:09 +0300
Message-Id: <838sd425l2.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> (message from Stefan
 Monnier on Sat, 19 Sep 2020 18:06:20 -0400)
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: 43519 <at> debbugs.gnu.org
> Date: Sat, 19 Sep 2020 18:06:20 -0400
> 
> > 	     ;;"-prospects" - more than one candidate
> > 	     (prospects-len (+ (string-width
> > 				(or determ (concat open-bracket close-bracket)))
> > 			       (string-width icomplete-separator)
> > 			       (+ 2 (string-width ellipsis)) ;; take {…} into account
> > 			       (string-width (buffer-string))))
> >              (prospects-max
> >               ;; Max total length to use, including the minibuffer content.
> >               (* (+ icomplete-prospects-height
> >                     ;; If the minibuffer content already uses up more than
> >                     ;; one line, increase the allowable space accordingly.
> >                     (/ prospects-len (window-width)))
> >                  (window-width)))
> 
> That's not relevant to the issue at hand.  I used `icomplete-mode` only
> as a vehicle to show the underlying behavior with a short recipe which
> exhibits a real-life problem.

TL;DR: Please describe those real-life problems in more detail.  I
hope my explanations below clarify why this is needed.

Details:

If you want the display engine to behave with after-strings the same
as with buffer text in this and similar cases, then this is AFAIU
impossible under the current design of the display code.  In
particular, functions that allow layout decisions by simulating
display treat overlay strings as a single unbreakable chunk of text,
and will not stop inside such strings, and so cannot provide the same
information they do when the text in the mini-window comes from a
buffer.  So the code in resize_mini_window and elsewhere cannot
possibly behave the same in the two variants of mini-window display
you provided in your test case.  Or at least I don't know how to make
it behave the same.

IOW, to the best of my knowledge and understanding, this is not a bug,
but a direct consequence of how the display code was designed.

Therefore, we are left with 2 possibilities:

  . Fix these problems on the application level.  In the case in
    point, that would mean for icomplete.el to augment its
    calculations of where to truncate the list of candidates so that
    the problem doesn't happen (and AFAICT it doesn't happen if the
    stuff to be displayed in the mini-window fits the mini-window
    after resizing it to max-mini-window-height).

  . Define in more detail what situations we would like to fix in the
    display code, so that we could install special ad-hoc changes
    there to handle those situations.  For example: is it true that in
    all of these situations starting the mini-window display at BOB
    would DTRT?  If so, I think this could be arranged.  If not, why
    not, and what is the more correct definition of the situations we
    want to handle?

> > What do you think is the underlying problem?
> 
> 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.  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

IOW, the basic logic is to show the last max-mini-window-height screen
lines of what's in mini-window.

However, when the window-start so computed is then examined by the
code which actually redisplays the mini-window, that code can override
the computed window-start if the position of point will not be visible
in the mini-window with that window-start in effect.  This actually
happens when the test code uses buffer text (not an overlay string) --
the computed window-start, which is in the middle of the "askdjf..."
text, is abandoned, and BOB is used instead.  This does NOT happen
with the overlay-string version, because the window-start point
computed by resize_mini_window is EOB, and that position is visible in
the window.

> >> (and as you know it's wickedly difficult to construct a string which
> >> will have "just the right size" to fit into the minibuffer window).
> > It doesn't have to be "just the right size", it could err on the safe
> > side.  It already attempts to do so, by avoiding truncation in the
> > middle of a candidate.  It should just do a better job, that's all.
> 
> And how do we generalize that to the case where the overlay contains
> newlines, TABs, chars in different scripts using different fonts,
> different faces, images, etc.... ?

Doesn't window-text-pixel-size provide a tool to solve at least some
of those problems?

>     (minibuffer-with-setup-hook
>         (lambda ()
>           (insert "hello")
>           (let ((ol (make-overlay (point) (point)))
>                 (max-mini-window-height 1)
>                 (text "askdjfhaklsjdfhlkasjdfhklasdhflkasdhflkajsdhflkashdfkljahsdlfkjahsdlfkjhasldkfhalskdjfhalskdfhlaksdhfklasdhflkasdhflkasdhflkajsdhklajsdgh"))
>             (save-excursion (insert text))
>             (sit-for 2)
>             (delete-region (point) (point-max))
>             (put-text-property 0 1 'cursor t text)
>             (overlay-put ol 'after-string text)
>             (sit-for 2)
>             (delete-overlay ol)))
>       (read-string "toto: "))

(Btw, people who read this should be aware that binding
max-mini-window-height like this doesn't work in general: the setting
must be in effect when redisplay runs.  It works here only because
there are sit-for calls.)

I believe I explained the issues above; if not, please ask specific
questions.

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

Without such a redesign we can only make ad-hoc changes for specific
situations.  If such ad-hoc changes are to be done in the display
engine, I need a better, more detailed (and more friendly) spec.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 20 Sep 2020 09:04:02 +0000
Resent-Message-ID: <handler.43519.B43519.160059263123284 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Gregory Heytings <ghe@HIDDEN>
Cc: 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.160059263123284
          (code B ref 43519); Sun, 20 Sep 2020 09:04:02 +0000
Received: (at 43519) by debbugs.gnu.org; 20 Sep 2020 09:03:51 +0000
Received: from localhost ([127.0.0.1]:48685 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kJvGB-00063U-Ka
	for submit <at> debbugs.gnu.org; Sun, 20 Sep 2020 05:03:51 -0400
Received: from eggs.gnu.org ([209.51.188.92]:45698)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1kJvG9-00063I-VU
 for 43519 <at> debbugs.gnu.org; Sun, 20 Sep 2020 05:03:50 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:60609)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1kJvG4-0008KE-Ax; Sun, 20 Sep 2020 05:03:44 -0400
Received: from [176.228.60.248] (port=2917 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1kJvG2-0005SF-J8; Sun, 20 Sep 2020 05:03:43 -0400
Date: Sun, 20 Sep 2020 12:03:41 +0300
Message-Id: <835z88251u.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <alpine.NEB.2.22.394.2009201009030453.20544@HIDDEN>
 (message from Gregory Heytings on Sun, 20 Sep 2020 08:27:55 +0000)
References: <alpine.NEB.2.22.394.2009201009030453.20544@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Sun, 20 Sep 2020 08:27:55 +0000
> From: Gregory Heytings <ghe@HIDDEN>
> cc: 43519 <at> debbugs.gnu.org
> 
> But the point is that there is clearly enough horizontal space, so there 
> is (or there does not seem to be) no reason to scroll horizontally.

There's no horizontal scroll.  What happens is that Emacs decides that
the mini-window's display will start at EOB.  I hope I've explained
why this happens in my previous message.

> > You are asking the display engine to do the impossible.
> 
> No.  With a minibuffer-only frame, the bug is not present.

With a minibuffer-only frame, mini-window resizing works very
differently: it resizes the entire frame.

> So it's feasible, and the display engine knows how to do it.

I'm sure we will welcome patches to make this happen in the other
cases.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Gregory Heytings <ghe@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 20 Sep 2020 10:13:01 +0000
Resent-Message-ID: <handler.43519.B43519.160059674113796 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.160059674113796
          (code B ref 43519); Sun, 20 Sep 2020 10:13:01 +0000
Received: (at 43519) by debbugs.gnu.org; 20 Sep 2020 10:12:21 +0000
Received: from localhost ([127.0.0.1]:48777 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kJwKT-0003aS-JW
	for submit <at> debbugs.gnu.org; Sun, 20 Sep 2020 06:12:21 -0400
Received: from mx.sdf.org ([205.166.94.24]:56310)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ghe@HIDDEN>) id 1kJwKQ-0003aI-3k
 for 43519 <at> debbugs.gnu.org; Sun, 20 Sep 2020 06:12:20 -0400
Received: from sdf.org (IDENT:ghe@HIDDEN [205.166.94.9])
 by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 08KACGZj001417
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO);
 Sun, 20 Sep 2020 10:12:17 GMT
Received: (from ghe@localhost)
 by sdf.org (8.15.2/8.12.8/Submit) id 08KACVcE000297;
 Sun, 20 Sep 2020 10:12:31 GMT
Date: Sun, 20 Sep 2020 10:12:14 +0000
From: Gregory Heytings <ghe@HIDDEN>
In-Reply-To: <835z88251u.fsf@HIDDEN>
Message-ID: <alpine.NEB.2.22.394.2009201144100453.25481@HIDDEN>
References: <alpine.NEB.2.22.394.2009201009030453.20544@HIDDEN>
 <835z88251u.fsf@HIDDEN>
User-Agent: Alpine 2.22 (NEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


Another note: with (setq resize-mini-windows nil) the bug disappears, the 
prompt is always visible even if the overlay text is too large.  So a more 
robust solution to the problem would be to do something like:

(add-hook 'icomplete-minibuffer-setup-hook (function (lambda () (setq resize-mini-windows nil) (enlarge-window N))))

with N replaced by the number of lines that we are about to display.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 20 Sep 2020 10:53:01 +0000
Resent-Message-ID: <handler.43519.B43519.16005991332175 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Gregory Heytings <ghe@HIDDEN>
Cc: 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.16005991332175
          (code B ref 43519); Sun, 20 Sep 2020 10:53:01 +0000
Received: (at 43519) by debbugs.gnu.org; 20 Sep 2020 10:52:13 +0000
Received: from localhost ([127.0.0.1]:48867 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kJwx2-0000Z0-N1
	for submit <at> debbugs.gnu.org; Sun, 20 Sep 2020 06:52:13 -0400
Received: from eggs.gnu.org ([209.51.188.92]:59718)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1kJwx0-0000Yn-U4
 for 43519 <at> debbugs.gnu.org; Sun, 20 Sep 2020 06:52:11 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:33139)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1kJwwv-0002rZ-K0; Sun, 20 Sep 2020 06:52:05 -0400
Received: from [176.228.60.248] (port=1917 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1kJwwu-0007VQ-VS; Sun, 20 Sep 2020 06:52:05 -0400
Date: Sun, 20 Sep 2020 13:52:04 +0300
Message-Id: <831riw2017.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <alpine.NEB.2.22.394.2009201144100453.25481@HIDDEN>
 (message from Gregory Heytings on Sun, 20 Sep 2020 10:12:14 +0000)
References: <alpine.NEB.2.22.394.2009201009030453.20544@HIDDEN>
 <835z88251u.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009201144100453.25481@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Sun, 20 Sep 2020 10:12:14 +0000
> From: Gregory Heytings <ghe@HIDDEN>
> cc: 43519 <at> debbugs.gnu.org
> 
> Another note: with (setq resize-mini-windows nil) the bug disappears, the 
> prompt is always visible even if the overlay text is too large.  So a more 
> robust solution to the problem would be to do something like:
> 
> (add-hook 'icomplete-minibuffer-setup-hook (function (lambda () (setq resize-mini-windows nil) (enlarge-window N))))
> 
> with N replaced by the number of lines that we are about to display.

If this is an acceptable solution, it is definitely fine by me.  But I
envision complaints from people who expect certain behavior from
mini-windows with large contents: the above effectively ignores their
settings.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Gregory Heytings <ghe@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 20 Sep 2020 21:05:02 +0000
Resent-Message-ID: <handler.43519.B43519.160063584923051 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: Stefan Monnier <monnier@HIDDEN>, 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.160063584923051
          (code B ref 43519); Sun, 20 Sep 2020 21:05:02 +0000
Received: (at 43519) by debbugs.gnu.org; 20 Sep 2020 21:04:09 +0000
Received: from localhost ([127.0.0.1]:52816 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kK6VF-0005zj-BR
	for submit <at> debbugs.gnu.org; Sun, 20 Sep 2020 17:04:09 -0400
Received: from mx.sdf.org ([205.166.94.24]:49963)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ghe@HIDDEN>) id 1kK6VC-0005zZ-IQ
 for 43519 <at> debbugs.gnu.org; Sun, 20 Sep 2020 17:04:07 -0400
Received: from sdf.org (IDENT:ghe@HIDDEN [205.166.94.9])
 by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 08KL45Ew002333
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO);
 Sun, 20 Sep 2020 21:04:05 GMT
Received: (from ghe@localhost)
 by sdf.org (8.15.2/8.12.8/Submit) id 08KL4KFp024763;
 Sun, 20 Sep 2020 21:04:20 GMT
Date: Sun, 20 Sep 2020 21:04:02 +0000
From: Gregory Heytings <ghe@HIDDEN>
In-Reply-To: <838sd425l2.fsf@HIDDEN>
Message-ID: <alpine.NEB.2.22.394.2009202237350453.31246@HIDDEN>
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
User-Agent: Alpine 2.22 (NEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


For some reason I did not receive a copy of your mail.  I see it now.

>
>  . Fix these problems on the application level.  In the case in
>    point, that would mean for icomplete.el to augment its
>    calculations of where to truncate the list of candidates so that
>    the problem doesn't happen (and AFAICT it doesn't happen if the
>    stuff to be displayed in the mini-window fits the mini-window
>    after resizing it to max-mini-window-height).
>

It is difficult to fix such problems on the application level.  If the 
stuff to be displayed in the mini-window fits the mini-window after 
resizing it to max-mini-window-height, the problem does not happen indeed. 
But the difficulty is precisely to create the stuff to be displayed in 
such a way that it fits the mini-window, because it can use a font that is 
not the default one, it can have embedded newlines, it can contain lines 
that are too wide for the mini-window, and so forth.

>
>  . Define in more detail what situations we would like to fix in the
>    display code, so that we could install special ad-hoc changes
>    there to handle those situations.  For example: is it true that in
>    all of these situations starting the mini-window display at BOB
>    would DTRT?  If so, I think this could be arranged.  If not, why
>    not, and what is the more correct definition of the situations we
>    want to handle?
>

See my proposal, which does exactly this.  Yes, it is true that in all of 
these situations starting the mini-window display at BOB would do the 
right thing.

>
> IOW, the basic logic is to show the last max-mini-window-height screen 
> lines of what's in mini-window.
>

Yes, and this is not desirable in certain cases, it should be possible to 
show the *first* max-mini-window-height screen lines of what's in 
mini-window.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Gregory Heytings <ghe@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 20 Sep 2020 21:32:01 +0000
Resent-Message-ID: <handler.43519.B43519.160063748925628 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: Stefan Monnier <monnier@HIDDEN>, 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.160063748925628
          (code B ref 43519); Sun, 20 Sep 2020 21:32:01 +0000
Received: (at 43519) by debbugs.gnu.org; 20 Sep 2020 21:31:29 +0000
Received: from localhost ([127.0.0.1]:52850 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kK6vg-0006fI-NL
	for submit <at> debbugs.gnu.org; Sun, 20 Sep 2020 17:31:28 -0400
Received: from mx.sdf.org ([205.166.94.24]:62798)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ghe@HIDDEN>) id 1kK6ve-0006f8-JQ
 for 43519 <at> debbugs.gnu.org; Sun, 20 Sep 2020 17:31:27 -0400
Received: from sdf.org (IDENT:ghe@HIDDEN [205.166.94.9])
 by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 08KLVOhK028476
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO);
 Sun, 20 Sep 2020 21:31:24 GMT
Received: (from ghe@localhost)
 by sdf.org (8.15.2/8.12.8/Submit) id 08KLVd8O012353;
 Sun, 20 Sep 2020 21:31:39 GMT
Date: Sun, 20 Sep 2020 21:31:21 +0000
From: Gregory Heytings <ghe@HIDDEN>
In-Reply-To: <alpine.NEB.2.22.394.2009202237350453.31246@HIDDEN>
Message-ID: <alpine.NEB.2.22.394.2009202327470453.3406@HIDDEN>
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009202237350453.31246@HIDDEN>
User-Agent: Alpine 2.22 (NEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


[Apparently my previous mail was not delivered, so I send it again.  I 
apologize if you receive it twice.]

After some further analysis, the problem here is in resize_mini_window().

In the comments one finds:

"Set W->start to the right place to begin display.  If the whole contents 
fit, start at the beginning.  Otherwise, start so as to make the end of 
the contents appear.  This is particularly important for y-or-n-p, but 
seems desirable generally."

I won't judge the "seems desirable generally", but in this case at least 
it is clearly not desirable, so there should be a way to do something 
else.

More precisely, in this case height > max_height, so

init_iterator (&it, w, ZV, ZV_BYTE, NULL, DEFAULT_FACE_ID);

is called, followed by

move_it_vertically_backward (&it, height - unit);

which does nothing given that height == unit, so start is set to ZV.

What I would suggest is to add a user option to set start to BEGV when 
height > max_height, which is what is needed here.  It would be reset to 
nil in read_minibuf() before calling minibuffer-setup-hook, and would be 
used in resize_mini_window() as follows:

/* Compute a suitable window start.  */
if (height > max_height && !EQ (Vstart_display_at_beginning_of_minibuffer, Qt))

This would not break any existing behavior.  Would this be a good way to 
solve that problem?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 20 Sep 2020 22:41:01 +0000
Resent-Message-ID: <handler.43519.B43519.16006416267696 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.16006416267696
          (code B ref 43519); Sun, 20 Sep 2020 22:41:01 +0000
Received: (at 43519) by debbugs.gnu.org; 20 Sep 2020 22:40:26 +0000
Received: from localhost ([127.0.0.1]:52920 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kK80P-000203-SV
	for submit <at> debbugs.gnu.org; Sun, 20 Sep 2020 18:40:26 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:62521)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1kK80N-0001ze-Tt
 for 43519 <at> debbugs.gnu.org; Sun, 20 Sep 2020 18:40:24 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 949588096B;
 Sun, 20 Sep 2020 18:40:18 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id A2D2180BA9;
 Sun, 20 Sep 2020 18:40:16 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1600641616;
 bh=MKEz0MWWU/EUnpV3Eks6XmURyemVBGDdolqnhEi93lc=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=pbM2pVD+N2Sss7yAHbu2Vq6lXt0Zd9U68CpMJZB08t5ELOAmnl+VDRnFzvnB+XnAO
 0I0sPOemE7/F30J57dQjkJrv7isnnZaRW8hnlPQvL8ySCBTdZZyxy6gNfqtdC5HGXa
 +mnBJiUD8kcgGD3v9XVAhZm3QCc97NwFAD7xccuq6P0F7OT0zDNbS1fK85vIBaNALk
 RlilkKKitWTNzAEpmUVqh3bgWgs0BxUmjib/17wBLInUl7AuStnd0DAp2B7UyPJS7H
 TtX9hGIeu48zaBW843AmDjIzSWOkeTqzHp5wn/yIWtuirbGhVszcRnTqZxR+9LlhLq
 txkhuMxkXD7Sg==
Received: from alfajor (unknown [45.72.232.131])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 6EB73120328;
 Sun, 20 Sep 2020 18:40:16 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwvd02g5bnp.fsf-monnier+emacs@HIDDEN>
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
Date: Sun, 20 Sep 2020 18:40:15 -0400
In-Reply-To: <838sd425l2.fsf@HIDDEN> (Eli Zaretskii's message of "Sun, 20 Sep
 2020 11:52:09 +0300")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.076 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Gregory Heytings <ghe@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 21 Sep 2020 06:51:01 +0000
Resent-Message-ID: <handler.43519.B43519.160067103028444 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: Stefan Monnier <monnier@HIDDEN>, 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.160067103028444
          (code B ref 43519); Mon, 21 Sep 2020 06:51:01 +0000
Received: (at 43519) by debbugs.gnu.org; 21 Sep 2020 06:50:30 +0000
Received: from localhost ([127.0.0.1]:53168 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kKFef-0007Oh-Ou
	for submit <at> debbugs.gnu.org; Mon, 21 Sep 2020 02:50:29 -0400
Received: from mx.sdf.org ([205.166.94.24]:55762)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ghe@HIDDEN>) id 1kKFec-0007OX-Dp
 for 43519 <at> debbugs.gnu.org; Mon, 21 Sep 2020 02:50:27 -0400
Received: from sdf.org (IDENT:ghe@HIDDEN [205.166.94.9])
 by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 08L6oO5K005900
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO);
 Mon, 21 Sep 2020 06:50:25 GMT
Received: (from ghe@localhost)
 by sdf.org (8.15.2/8.12.8/Submit) id 08L6odG2027477;
 Mon, 21 Sep 2020 06:50:39 GMT
Date: Mon, 21 Sep 2020 06:50:22 +0000
From: Gregory Heytings <ghe@HIDDEN>
In-Reply-To: <alpine.NEB.2.22.394.2009202327470453.3406@HIDDEN>
Message-ID: <alpine.NEB.2.22.394.2009210836270453.4535@HIDDEN>
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009202237350453.31246@HIDDEN>
 <alpine.NEB.2.22.394.2009202327470453.3406@HIDDEN>
User-Agent: Alpine 2.22 (NEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


>
> What I would suggest is to add a user option to set start to BEGV when 
> height > max_height, which is what is needed here.  It would be reset to 
> nil in read_minibuf() before calling minibuffer-setup-hook, and would be 
> used in resize_mini_window() as follows:
>
> /* Compute a suitable window start.  */
> if (height > max_height && !EQ (Vstart_display_at_beginning_of_minibuffer, Qt))
>
> This would not break any existing behavior.  Would this be a good way to 
> solve that problem?
>

After further testing, doing this is not enough, because it is necessary 
to update height even when start_display_at_beginning_of_minibuffer.  So 
the code should be:

if (height > max_height && !EQ (Vstart_display_at_beginning_of_minibuffer, Qt))
{
   ...
}
else
{
   if (height > max_height) height = (max_height / unit) * unit;
   SET_TEXT_POS (start, BEGV, BEGV_BYTE);
}

Another note to answer Eli's previous questions:

>
>  . Define in more detail what situations we would like to fix in the
>    display code, so that we could install special ad-hoc changes
>    there to handle those situations.  For example: is it true that in
>    all of these situations starting the mini-window display at BOB
>    would DTRT?  If so, I think this could be arranged.  If not, why
>    not, and what is the more correct definition of the situations we
>    want to handle?
>

It is "true that in all of these situations starting the mini-window 
display at BOB would DTRT", but it is also true that in all of these 
situations the height overflow is due to an overlay at EOB.  So another 
solution, which I think would be even better, but might change the 
existing behavior marginally, would be to calculate the height two times, 
once at EOB and once at EOB-1.  With this Emacs would detect by itself the 
situations in which it is better to show the first max-mini-window-height 
lines instead of the last max-mini-window-height lines, and it would not 
be necessary to explicitly set a variable in minibuffer-setup-hook.  The 
code would be:

if (it.line_wrap == TRUNCATE)
   height_near_eob = height = unit;
else
{
   last_height = 0;
   move_it_to (&it, ZV - 1, -1, -1, -1, MOVE_TO_POS);
   if (it.max_ascent == 0 && it.max_descent == 0)
     height_near_eob = it.current_y + last_height;
   else
     height_near_eob = it.current_y + it.max_ascent + it.max_descent;
   height_near_eob -= min (it.extra_line_spacing, it.max_extra_line_spacing);
   move_it_to (&it, ZV, -1, -1, -1, MOVE_TO_POS);
   ...
}

if (height > max_height && height_near_eob > max_height)
{
   ...
}
else
{
   if (height > max_height) height = (max_height / unit) * unit;
   SET_TEXT_POS (start, BEGV, BEGV_BYTE);
}

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Gregory Heytings <ghe@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 21 Sep 2020 07:05:02 +0000
Resent-Message-ID: <handler.43519.B43519.160067184929810 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.160067184929810
          (code B ref 43519); Mon, 21 Sep 2020 07:05:02 +0000
Received: (at 43519) by debbugs.gnu.org; 21 Sep 2020 07:04:09 +0000
Received: from localhost ([127.0.0.1]:53186 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kKFrt-0007kj-4c
	for submit <at> debbugs.gnu.org; Mon, 21 Sep 2020 03:04:09 -0400
Received: from mx.sdf.org ([205.166.94.24]:55093)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ghe@HIDDEN>) id 1kKFrq-0007kW-U4
 for 43519 <at> debbugs.gnu.org; Mon, 21 Sep 2020 03:04:07 -0400
Received: from sdf.org (IDENT:ghe@HIDDEN [205.166.94.9])
 by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 08L745ix002053
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO);
 Mon, 21 Sep 2020 07:04:05 GMT
Received: (from ghe@localhost)
 by sdf.org (8.15.2/8.12.8/Submit) id 08L74IhG002162;
 Mon, 21 Sep 2020 07:04:18 GMT
Date: Mon, 21 Sep 2020 07:04:02 +0000
From: Gregory Heytings <ghe@HIDDEN>
In-Reply-To: <jwvd02g5bnp.fsf-monnier+emacs@HIDDEN>
Message-ID: <alpine.NEB.2.22.394.2009210853040453.5334@HIDDEN>
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
 <jwvd02g5bnp.fsf-monnier+emacs@HIDDEN>
User-Agent: Alpine 2.22 (NEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


>
> IIUC the problem only shows up because of the auto-resizing of the 
> minibuffer window, right?
>

Yes.

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

Yes, but setting these two variables have a very different effect. 
Setting resize-mini-windows to nil means that resize_mini_window() will 
return immediately after setting the start of display to its default value 
(namely BEGV).  Setting max-mini-window-height to 1 does not have that 
effect, resize_mini_window() computes the height that would be necessary 
to display the content of the minibuffer, compares it to the height that 
is actually available, and uses that height to calculate the start of 
display, by moving backward from the height that would be necessary (which 
does nothing in this case, given that height == unit).

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 21 Sep 2020 14:03:02 +0000
Resent-Message-ID: <handler.43519.B43519.160069695715027 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Gregory Heytings <ghe@HIDDEN>
Cc: monnier@HIDDEN, 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.160069695715027
          (code B ref 43519); Mon, 21 Sep 2020 14:03:02 +0000
Received: (at 43519) by debbugs.gnu.org; 21 Sep 2020 14:02:37 +0000
Received: from localhost ([127.0.0.1]:55484 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kKMOr-0003uI-1V
	for submit <at> debbugs.gnu.org; Mon, 21 Sep 2020 10:02:37 -0400
Received: from eggs.gnu.org ([209.51.188.92]:58274)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1kKMOn-0003u0-FE
 for 43519 <at> debbugs.gnu.org; Mon, 21 Sep 2020 10:02:35 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:57461)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1kKMOg-0007us-9m; Mon, 21 Sep 2020 10:02:26 -0400
Received: from [176.228.60.248] (port=2239 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1kKMOf-0002U6-HS; Mon, 21 Sep 2020 10:02:25 -0400
Date: Mon, 21 Sep 2020 17:02:27 +0300
Message-Id: <83363bz0r0.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <alpine.NEB.2.22.394.2009202237350453.31246@HIDDEN>
 (message from Gregory Heytings on Sun, 20 Sep 2020 21:04:02 +0000)
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009202237350453.31246@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Sun, 20 Sep 2020 21:04:02 +0000
> From: Gregory Heytings <ghe@HIDDEN>
> cc: Stefan Monnier <monnier@HIDDEN>, 43519 <at> debbugs.gnu.org
> 
> It is difficult to fix such problems on the application level. If the stuff to be displayed in the mini-window fits the mini-window after resizing it to max-mini-window-height, the problem does not happen indeed. But the difficulty is precisely to create the stuff to be displayed in such a way that it fits the mini-window, because it can use a font that is not the default one, it can have embedded newlines, it can contain lines that are too wide for the mini-window, and so forth.

I believe using window-text-pixel-size (which I already mentioned
several times) will avoid any such difficulties, since that function
takes all of those complications into account.  Therefore, I still
don't understand why this approach is not being explored more
actively.

> it is true that in all of these situations starting the mini-window display at BOB would do the right thing.

Are you sure?  What if the prompt is longer than a screen line (i.e.,
the prompt itself is continued on the 2nd and subsequent screen
lines)?  If the prompt is long, but the list of candidates is short,
starting the mini-window display at BOB might fail to show some or all
of the candidates, because the long prompt uses up most or all of the
mini-window screen estate.

>     IOW, the basic logic is to show the last max-mini-window-height screen lines of what's in mini-window.
> 
> Yes, and this is not desirable in certain cases, it should be possible to show the *first* max-mini-window-height screen lines of what's in mini-window. 

Showing the last part is in general a better strategy in the use cases
relevant to the mini-window, which are about user interaction.  I
believe you assume that starting at BOB still shows enough of the text
to allow the user to interact intelligently, but those are not the
only cases we should keep in mind, since the prompt doesn't have to be
short enough for that assumption to be true.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 21 Sep 2020 14:05:02 +0000
Resent-Message-ID: <handler.43519.B43519.160069708015226 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Gregory Heytings <ghe@HIDDEN>
Cc: monnier@HIDDEN, 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.160069708015226
          (code B ref 43519); Mon, 21 Sep 2020 14:05:02 +0000
Received: (at 43519) by debbugs.gnu.org; 21 Sep 2020 14:04:40 +0000
Received: from localhost ([127.0.0.1]:55491 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kKMQl-0003xQ-4A
	for submit <at> debbugs.gnu.org; Mon, 21 Sep 2020 10:04:40 -0400
Received: from eggs.gnu.org ([209.51.188.92]:59158)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1kKMQi-0003xD-Ct
 for 43519 <at> debbugs.gnu.org; Mon, 21 Sep 2020 10:04:33 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:57501)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1kKMQc-00089F-OG; Mon, 21 Sep 2020 10:04:26 -0400
Received: from [176.228.60.248] (port=2362 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1kKMQc-0002dQ-6o; Mon, 21 Sep 2020 10:04:26 -0400
Date: Mon, 21 Sep 2020 17:04:28 +0300
Message-Id: <83zh5jxm37.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <alpine.NEB.2.22.394.2009202327470453.3406@HIDDEN>
 (message from Gregory Heytings on Sun, 20 Sep 2020 21:31:21 +0000)
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009202237350453.31246@HIDDEN>
 <alpine.NEB.2.22.394.2009202327470453.3406@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Sun, 20 Sep 2020 21:31:21 +0000
> From: Gregory Heytings <ghe@HIDDEN>
> cc: Stefan Monnier <monnier@HIDDEN>, 43519 <at> debbugs.gnu.org
> 
> "Set W->start to the right place to begin display. If the whole contents fit, start at the beginning. Otherwise, start so as to make the end of the contents appear. This is particularly important for y-or-n-p, but seems desirable generally."
> 
> I won't judge the "seems desirable generally", but in this case at least it is clearly not desirable, so there should be a way to do something else.

The problem is what is that "something else", exactly, and how to
specify that to redisplay in terms it can understand and follow.

> More precisely, in this case height > max_height, so
> 
> init_iterator (&it, w, ZV, ZV_BYTE, NULL, DEFAULT_FACE_ID);
> 
> is called, followed by
> 
> move_it_vertically_backward (&it, height - unit);
> 
> which does nothing given that height == unit, so start is set to ZV.

height == unit only when max_height = 1.  But the same problem will
happen if max_height = 2 and the stuff we want to display takes more
than 2 screen lines, right?  In those other cases, this code doesn't
"do nothing".

> What I would suggest is to add a user option to set start to BEGV when height > max_height, which is what is needed here. It would be reset to nil in read_minibuf() before calling minibuffer-setup-hook, and would be used in resize_mini_window() as follows:
> 
> /* Compute a suitable window start.  */
> if (height > max_height && !EQ (Vstart_display_at_beginning_of_minibuffer, Qt))

First, I'm not yet convinced starting at BOB is always TRT.  For
example, what if the prompt is very long and takes up more than one
screen line?

Second, it is not enough to set window-start to a particular buffer
position, we must also make sure the position of point will be visible
with that window-start.  Otherwise, redisplay will override the
window-start we set.  So, before setting this flag, the application
will still need some code to see if BOB is pertinent, i.e. consider
the resulting layout, which is something you wanted to avoid in the
first place.

And finally, if a sufficiently generic solution that doesn't require
external knobs can be devised, I'd prefer doing TRT automatically,
without imposing such non-trivial settings on the application.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 21 Sep 2020 14:06:02 +0000
Resent-Message-ID: <handler.43519.B43519.160069715415353 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.160069715415353
          (code B ref 43519); Mon, 21 Sep 2020 14:06:02 +0000
Received: (at 43519) by debbugs.gnu.org; 21 Sep 2020 14:05:54 +0000
Received: from localhost ([127.0.0.1]:55496 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kKMS1-0003zZ-JL
	for submit <at> debbugs.gnu.org; Mon, 21 Sep 2020 10:05:53 -0400
Received: from eggs.gnu.org ([209.51.188.92]:59570)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1kKMS0-0003zM-2u
 for 43519 <at> debbugs.gnu.org; Mon, 21 Sep 2020 10:05:52 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:57525)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1kKMRu-0008Pz-Tk; Mon, 21 Sep 2020 10:05:46 -0400
Received: from [176.228.60.248] (port=2438 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1kKMRo-0002mC-Cz; Mon, 21 Sep 2020 10:05:46 -0400
Date: Mon, 21 Sep 2020 17:05:42 +0300
Message-Id: <83y2l3xm15.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <jwvd02g5bnp.fsf-monnier+emacs@HIDDEN> (message from Stefan
 Monnier on Sun, 20 Sep 2020 18:40:15 -0400)
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
 <jwvd02g5bnp.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: 43519 <at> debbugs.gnu.org
> Date: Sun, 20 Sep 2020 18:40:15 -0400
> 
> > 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.

We do have horizontal scrolling in Emacs: when lines are truncated.
See auto-hscroll and scroll-left/right.  That's what "horizontal
scrolling" means to me in the context of Emacs.

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

Because this way we have no control on where the mini-window's display
will start, and consequently what will be visible in the mini-window.
In particular, if point is at EOB, redisplay could (and normally does)
decide not to position point on the last screen line of the window,
which means we may have some of the text not visible for no good
reason -- not a good thing when user interaction is concerned.

More generally, since the mini-window is usually small and user
interaction requires to make sure the user sees the important parts of
the buffer text (if not all of it), we want tighter control on what
will end up on display, and the way to do that is via setting
window-start.

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

Disabling resize-mini-windows means the mini-window is not resized at
all as part of redisplay.  It doesn't mean the mini-window will always
be a single screen line.  The user or a Lisp program can resize it "by
hand", and it will stay that way until manually resized again.
Basically, disabling this means either the user doesn't care about
what will be visible in the mini-window, or a Lisp program takes the
responsibility of resizing the mini-window as needed.

When resize-mini-windows is disabled, we always start the display at
BOB.  That might be the desired outcome in the particular case you
used as the example, but as I wrote elsewhere, I'm not at all sure
this is TRT for all of the use cases we are discussing: for example,
what if the prompt is longer than a single screen line?  Worse, with
the stuff to display in the mini-window long enough, leaving the
mini-window not resized will obscure large portions of that stuff, so
this cure sounds to me worse than the disease.

And besides, this is a user option, so having some code disregard it
is unfriendly, to say the least, even if we do that temporarily.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 21 Sep 2020 14:18:01 +0000
Resent-Message-ID: <handler.43519.B43519.160069785224377 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Gregory Heytings <ghe@HIDDEN>
Cc: monnier@HIDDEN, 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.160069785224377
          (code B ref 43519); Mon, 21 Sep 2020 14:18:01 +0000
Received: (at 43519) by debbugs.gnu.org; 21 Sep 2020 14:17:32 +0000
Received: from localhost ([127.0.0.1]:55556 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kKMdI-0006Kt-Am
	for submit <at> debbugs.gnu.org; Mon, 21 Sep 2020 10:17:32 -0400
Received: from eggs.gnu.org ([209.51.188.92]:35346)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1kKMdG-0006Fp-1N
 for 43519 <at> debbugs.gnu.org; Mon, 21 Sep 2020 10:17:30 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:57718)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1kKMd8-0001jO-9l; Mon, 21 Sep 2020 10:17:22 -0400
Received: from [176.228.60.248] (port=3156 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1kKMd7-000419-Iu; Mon, 21 Sep 2020 10:17:22 -0400
Date: Mon, 21 Sep 2020 17:17:23 +0300
Message-Id: <83tuvrxlho.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <alpine.NEB.2.22.394.2009210836270453.4535@HIDDEN>
 (message from Gregory Heytings on Mon, 21 Sep 2020 06:50:22 +0000)
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009202237350453.31246@HIDDEN>
 <alpine.NEB.2.22.394.2009202327470453.3406@HIDDEN>
 <alpine.NEB.2.22.394.2009210836270453.4535@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Mon, 21 Sep 2020 06:50:22 +0000
> From: Gregory Heytings <ghe@HIDDEN>
> cc: Stefan Monnier <monnier@HIDDEN>, 43519 <at> debbugs.gnu.org
> 
> It is "true that in all of these situations starting the mini-window display at BOB would DTRT", but it is also true that in all of these situations the height overflow is due to an overlay at EOB.

By "height overflow" you mean the fact that max-mini-window-height
screen lines aren't enough to display all of the stuff we want in the
mini-window?  If so, you are considering only a narrow class of use
cases.  In other use cases, we could have a very long prompt, for
example.  Or we could even have a tall enough image there.  Then
reasons for "overflow" could be different.

> So another solution, which I think would be even better, but might change the existing behavior marginally, would be to calculate the height two times, once at EOB and once at EOB-1.

This assumes that there's no overlay strings at EOB-1?  Why would we
assume something like that?  It again narrows the set of use cases
which will be handled properly.

It also seems to assume that the prompt (which ends at EOB) is much
shorter than the overlay string displayed beyond EOB.  But this is not
guaranteed: it could be the other way around, in which case the
proposed changes will not show the most important part of the
mini-window's display.

My suggestion is to go back to the "start display at BOB" assertion
(which is not true in general), and try to find a more general/more
accurate one.  For example: would it be okay to start the display at
the beginning of the screen line where we end up after
move_it_vertically_backward returns?  This way, if the prompt is very
long, we will start in its middle (at the beginning of one of the
continuation lines used to display the prompt), but we will show as
much of the overlay string as possible.  This strategy will also
handle minibuffer prompts that don't use overlay strings at all better
than if we start at BOB.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Gregory Heytings <ghe@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 21 Sep 2020 14:19:02 +0000
Resent-Message-ID: <handler.43519.B43519.160069789424988 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: monnier@HIDDEN, 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.160069789424988
          (code B ref 43519); Mon, 21 Sep 2020 14:19:02 +0000
Received: (at 43519) by debbugs.gnu.org; 21 Sep 2020 14:18:14 +0000
Received: from localhost ([127.0.0.1]:55560 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kKMdx-0006Uy-RV
	for submit <at> debbugs.gnu.org; Mon, 21 Sep 2020 10:18:14 -0400
Received: from mx.sdf.org ([205.166.94.24]:54854)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ghe@HIDDEN>) id 1kKMdv-0006Un-9T
 for 43519 <at> debbugs.gnu.org; Mon, 21 Sep 2020 10:18:12 -0400
Received: from sdf.org (IDENT:ghe@HIDDEN [205.166.94.9])
 by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 08LEIAhE006166
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO);
 Mon, 21 Sep 2020 14:18:10 GMT
Received: (from ghe@localhost)
 by sdf.org (8.15.2/8.12.8/Submit) id 08LEINvQ016464;
 Mon, 21 Sep 2020 14:18:23 GMT
Date: Mon, 21 Sep 2020 14:18:07 +0000
From: Gregory Heytings <ghe@HIDDEN>
In-Reply-To: <83363bz0r0.fsf@HIDDEN>
Message-ID: <alpine.NEB.2.22.394.2009211603470453.9454@HIDDEN>
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009202237350453.31246@HIDDEN>
 <83363bz0r0.fsf@HIDDEN>
User-Agent: Alpine 2.22 (NEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


>
> I believe using window-text-pixel-size (which I already mentioned 
> several times) will avoid any such difficulties, since that function 
> takes all of those complications into account.  Therefore, I still don't 
> understand why this approach is not being explored more actively.
>

This I don't know or understand either.  My guess is that creating a 
candidate list by adding one candidate at a time and checking with 
window-text-pixel-size if the result is too large would be inefficient. 
This could be improved with a kind of binary search of course.

>> it is true that in all of these situations starting the mini-window 
>> display at BOB would do the right thing.
>
> Are you sure?  What if the prompt is longer than a screen line (i.e., 
> the prompt itself is continued on the 2nd and subsequent screen lines)? 
> If the prompt is long, but the list of candidates is short, starting the 
> mini-window display at BOB might fail to show some or all of the 
> candidates, because the long prompt uses up most or all of the 
> mini-window screen estate.
>

Yes I'm sure.  In the case you mention indeed some candidates will not be 
displayed, but that's not a problem because most of the time all 
candidates are not displayed anyway.  Of course there is the case when the 
prompt is, say, two characters less than the mini-window width, in which 
case no candidates will be displayed (if the user has (setq 
max-mini-window-width 1)), but this is unlikely to happen, and the default 
value of max-mini-window-width is 0.25 anyway.

>>> IOW, the basic logic is to show the last max-mini-window-height screen 
>>> lines of what's in mini-window.
>>
>> Yes, and this is not desirable in certain cases, it should be possible 
>> to show the *first* max-mini-window-height screen lines of what's in 
>> mini-window.
>
> Showing the last part is in general a better strategy in the use cases 
> relevant to the mini-window, which are about user interaction.
>

In general yes, but not when displaying completion candidates with an 
overlay at EOB, with the point before the overlay text.  In that case you 
start with a blinking cursor at the top left of the minibuffer, without 
any indication of what you are doing or should do.

>
> I believe you assume that starting at BOB still shows enough of the text 
> to allow the user to interact intelligently, but those are not the only 
> cases we should keep in mind, since the prompt doesn't have to be short 
> enough for that assumption to be true.
>

I tested this, and it works, even with overlong prompts.  In that case 
(for example with (setq max-mini-window-width 1) and a prompt wider than 
the mini-window width) the prompt disappears, but this is expected, and 
it's a corner case that almost never happens.  Moreover when displaying 
completion candidates you don't start with a long prompt (except, again, 
in corner cases).

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Gregory Heytings <ghe@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 21 Sep 2020 14:32:01 +0000
Resent-Message-ID: <handler.43519.B43519.160069871426502 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: monnier@HIDDEN, 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.160069871426502
          (code B ref 43519); Mon, 21 Sep 2020 14:32:01 +0000
Received: (at 43519) by debbugs.gnu.org; 21 Sep 2020 14:31:54 +0000
Received: from localhost ([127.0.0.1]:55636 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kKMrC-0006tO-BG
	for submit <at> debbugs.gnu.org; Mon, 21 Sep 2020 10:31:54 -0400
Received: from mx.sdf.org ([205.166.94.24]:53569)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ghe@HIDDEN>) id 1kKMrA-0006tF-Lx
 for 43519 <at> debbugs.gnu.org; Mon, 21 Sep 2020 10:31:53 -0400
Received: from sdf.org (IDENT:ghe@HIDDEN [205.166.94.9])
 by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 08LEVptA021561
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO);
 Mon, 21 Sep 2020 14:31:52 GMT
Received: (from ghe@localhost)
 by sdf.org (8.15.2/8.12.8/Submit) id 08LEW79m007049;
 Mon, 21 Sep 2020 14:32:07 GMT
Date: Mon, 21 Sep 2020 14:31:49 +0000
From: Gregory Heytings <ghe@HIDDEN>
In-Reply-To: <83zh5jxm37.fsf@HIDDEN>
Message-ID: <alpine.NEB.2.22.394.2009211621050453.9454@HIDDEN>
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009202237350453.31246@HIDDEN>
 <alpine.NEB.2.22.394.2009202327470453.3406@HIDDEN>
 <83zh5jxm37.fsf@HIDDEN>
User-Agent: Alpine 2.22 (NEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


>> More precisely, in this case height > max_height, so
>>
>> init_iterator (&it, w, ZV, ZV_BYTE, NULL, DEFAULT_FACE_ID);
>>
>> is called, followed by
>>
>> move_it_vertically_backward (&it, height - unit);
>>
>> which does nothing given that height == unit, so start is set to ZV.
>
> height == unit only when max_height = 1. But the same problem will 
> happen if max_height = 2 and the stuff we want to display takes more 
> than 2 screen lines, right?  In those other cases, this code doesn't "do 
> nothing".
>

Yes of course, I was commenting under the assumtion that (setq 
max-mini-window-height 1), with which this thread started.  Indeed the 
code does not "do nothing" when max_height is > 1.

>
>> What I would suggest is to add a user option to set start to BEGV when 
>> height > max_height, which is what is needed here. It would be reset to 
>> nil in read_minibuf() before calling minibuffer-setup-hook, and would 
>> be used in resize_mini_window() as follows:
>>
>> /* Compute a suitable window start.  */
>> if (height > max_height && !EQ (Vstart_display_at_beginning_of_minibuffer, Qt))
>
> First, I'm not yet convinced starting at BOB is always TRT.  For 
> example, what if the prompt is very long and takes up more than one 
> screen line?
>

I tested this.  In that case (with max_height = 1) starting at BOB is not 
a problem, because the display engine with override this and display the 
point.  The prompt will be hidden, but this is expected.  It would happen, 
say, when you are completing a file name in a sub-sub-sub-...-directory 
with max_height = 1.

>
> Second, it is not enough to set window-start to a particular buffer 
> position, we must also make sure the position of point will be visible 
> with that window-start.  Otherwise, redisplay will override the 
> window-start we set.  So, before setting this flag, the application will 
> still need some code to see if BOB is pertinent, i.e. consider the 
> resulting layout, which is something you wanted to avoid in the first 
> place.
>

Note that this case (starting display at BOB and having point outside of 
the resulting display area) is highly unlikely.  When it happens, as you 
write, redisplay overrides the window-start that has been set here, and 
it's okay if it does.

>
> And finally, if a sufficiently generic solution that doesn't require 
> external knobs can be devised, I'd prefer doing TRT automatically, 
> without imposing such non-trivial settings on the application.
>

Yes, hence my second proposal, which checks height at EOB and at EOB-1.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 21 Sep 2020 14:46:01 +0000
Resent-Message-ID: <handler.43519.B43519.160069951828995 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Gregory Heytings <ghe@HIDDEN>
Cc: monnier@HIDDEN, 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.160069951828995
          (code B ref 43519); Mon, 21 Sep 2020 14:46:01 +0000
Received: (at 43519) by debbugs.gnu.org; 21 Sep 2020 14:45:18 +0000
Received: from localhost ([127.0.0.1]:55716 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kKN49-0007Wv-QS
	for submit <at> debbugs.gnu.org; Mon, 21 Sep 2020 10:45:18 -0400
Received: from eggs.gnu.org ([209.51.188.92]:46414)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1kKN47-0007Pj-Js
 for 43519 <at> debbugs.gnu.org; Mon, 21 Sep 2020 10:45:16 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:58262)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1kKN41-0006A5-Tc; Mon, 21 Sep 2020 10:45:10 -0400
Received: from [176.228.60.248] (port=4858 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1kKN3z-0008BU-BK; Mon, 21 Sep 2020 10:45:09 -0400
Date: Mon, 21 Sep 2020 17:45:08 +0300
Message-Id: <83pn6fxk7f.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <alpine.NEB.2.22.394.2009211603470453.9454@HIDDEN>
 (message from Gregory Heytings on Mon, 21 Sep 2020 14:18:07 +0000)
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009202237350453.31246@HIDDEN>
 <83363bz0r0.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009211603470453.9454@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Mon, 21 Sep 2020 14:18:07 +0000
> From: Gregory Heytings <ghe@HIDDEN>
> cc: monnier@HIDDEN, 43519 <at> debbugs.gnu.org
> 
> > I believe using window-text-pixel-size (which I already mentioned 
> > several times) will avoid any such difficulties, since that function 
> > takes all of those complications into account.  Therefore, I still don't 
> > understand why this approach is not being explored more actively.
> 
> This I don't know or understand either.  My guess is that creating a 
> candidate list by adding one candidate at a time and checking with 
> window-text-pixel-size if the result is too large would be inefficient. 

Even if the implementation indeed passes candidates through
window-text-pixel-size one by one, it is not clear to me that the
result will be slow enough to annoy.  We are talking about user
interaction, where speed is not that important.

In any case, I'd want to see numbers before deciding that this is
unacceptable.

> >> it is true that in all of these situations starting the mini-window 
> >> display at BOB would do the right thing.
> >
> > Are you sure?  What if the prompt is longer than a screen line (i.e., 
> > the prompt itself is continued on the 2nd and subsequent screen lines)? 
> > If the prompt is long, but the list of candidates is short, starting the 
> > mini-window display at BOB might fail to show some or all of the 
> > candidates, because the long prompt uses up most or all of the 
> > mini-window screen estate.
> 
> Yes I'm sure.  In the case you mention indeed some candidates will not be 
> displayed, but that's not a problem because most of the time all 
> candidates are not displayed anyway.

But with long enough prompt, you can have _none_ of the candidates
displayed.

> Of course there is the case when the prompt is, say, two characters
> less than the mini-window width, in which case no candidates will be
> displayed (if the user has (setq max-mini-window-width 1)), but this
> is unlikely to happen

"Unlikely to happen" is not a good guideline for making changes in the
display code, IME.  Guess what? most of the things I considered
"unlikely" did happen eventually.

So I prefer a more generally correct solution, especially when it's
not hard to implement.
> > Showing the last part is in general a better strategy in the use cases 
> > relevant to the mini-window, which are about user interaction.
> 
> In general yes, but not when displaying completion candidates with an 
> overlay at EOB, with the point before the overlay text.

I'm not sure the use case with overlays is indeed the indicator that a
different strategy is needed.  but even if it is, the changes you
proposed don't test for the existence of such an overlay, they test
something else, and thus can affect unrelated use cases.

> In that case you start with a blinking cursor at the top left of the
> minibuffer, without any indication of what you are doing or should
> do.

Are you talking about what we see today?  I'm not arguing to leave it
unchanged, I'm talking about what would be the better solution, and
starting always at BOB sounds sub-optimal to me.

> > I believe you assume that starting at BOB still shows enough of the text 
> > to allow the user to interact intelligently, but those are not the only 
> > cases we should keep in mind, since the prompt doesn't have to be short 
> > enough for that assumption to be true.
> 
> I tested this, and it works, even with overlong prompts.  In that case 
> (for example with (setq max-mini-window-width 1) and a prompt wider than 
> the mini-window width) the prompt disappears, but this is expected, and 
> it's a corner case that almost never happens.

The solution I proposed in my other message (assuming that it is
accepted) is more general, I think.  It also covers "corner cases"
which you are willing to disregard.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 21 Sep 2020 14:48:02 +0000
Resent-Message-ID: <handler.43519.B43519.16006996593662 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Gregory Heytings <ghe@HIDDEN>
Cc: monnier@HIDDEN, 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.16006996593662
          (code B ref 43519); Mon, 21 Sep 2020 14:48:02 +0000
Received: (at 43519) by debbugs.gnu.org; 21 Sep 2020 14:47:39 +0000
Received: from localhost ([127.0.0.1]:55722 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kKN6Q-0000ws-PN
	for submit <at> debbugs.gnu.org; Mon, 21 Sep 2020 10:47:39 -0400
Received: from eggs.gnu.org ([209.51.188.92]:47172)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1kKN6O-0000rs-9d
 for 43519 <at> debbugs.gnu.org; Mon, 21 Sep 2020 10:47:37 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:58295)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1kKN6H-0006Zt-U5; Mon, 21 Sep 2020 10:47:30 -0400
Received: from [176.228.60.248] (port=4998 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1kKN68-0008P3-Fa; Mon, 21 Sep 2020 10:47:23 -0400
Date: Mon, 21 Sep 2020 17:47:22 +0300
Message-Id: <83o8lzxk3p.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <alpine.NEB.2.22.394.2009211621050453.9454@HIDDEN>
 (message from Gregory Heytings on Mon, 21 Sep 2020 14:31:49 +0000)
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009202237350453.31246@HIDDEN>
 <alpine.NEB.2.22.394.2009202327470453.3406@HIDDEN>
 <83zh5jxm37.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009211621050453.9454@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Mon, 21 Sep 2020 14:31:49 +0000
> From: Gregory Heytings <ghe@HIDDEN>
> cc: monnier@HIDDEN, 43519 <at> debbugs.gnu.org
> 
> Yes, hence my second proposal, which checks height at EOB and at EOB-1.

That assumes L2R text, btw, among other problems.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Gregory Heytings <ghe@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 21 Sep 2020 15:03:02 +0000
Resent-Message-ID: <handler.43519.B43519.160070055913250 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: monnier@HIDDEN, 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.160070055913250
          (code B ref 43519); Mon, 21 Sep 2020 15:03:02 +0000
Received: (at 43519) by debbugs.gnu.org; 21 Sep 2020 15:02:39 +0000
Received: from localhost ([127.0.0.1]:55759 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kKNKw-0003RL-Rs
	for submit <at> debbugs.gnu.org; Mon, 21 Sep 2020 11:02:39 -0400
Received: from mx.sdf.org ([205.166.94.24]:51777)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ghe@HIDDEN>) id 1kKNKs-0003O7-TI
 for 43519 <at> debbugs.gnu.org; Mon, 21 Sep 2020 11:02:37 -0400
Received: from sdf.org (IDENT:ghe@HIDDEN [205.166.94.9])
 by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 08LF2XWJ008630
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO);
 Mon, 21 Sep 2020 15:02:34 GMT
Received: (from ghe@localhost)
 by sdf.org (8.15.2/8.12.8/Submit) id 08LF2mg3019942;
 Mon, 21 Sep 2020 15:02:48 GMT
Date: Mon, 21 Sep 2020 15:02:31 +0000
From: Gregory Heytings <ghe@HIDDEN>
In-Reply-To: <83tuvrxlho.fsf@HIDDEN>
Message-ID: <alpine.NEB.2.22.394.2009211633090453.11632@HIDDEN>
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009202237350453.31246@HIDDEN>
 <alpine.NEB.2.22.394.2009202327470453.3406@HIDDEN>
 <alpine.NEB.2.22.394.2009210836270453.4535@HIDDEN>
 <83tuvrxlho.fsf@HIDDEN>
User-Agent: Alpine 2.22 (NEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


>> It is "true that in all of these situations starting the mini-window 
>> display at BOB would DTRT", but it is also true that in all of these 
>> situations the height overflow is due to an overlay at EOB.
>
> By "height overflow" you mean the fact that max-mini-window-height
> screen lines aren't enough to display all of the stuff we want in the
> mini-window?
>

Yes.

>
> If so, you are considering only a narrow class of use cases.  In other 
> use cases, we could have a very long prompt, for example.  Or we could 
> even have a tall enough image there.  Then reasons for "overflow" could 
> be different.
>

I already commented the case of a very long prompt.  For a tall enough 
image, I don't know.

>
>> So another solution, which I think would be even better, but might 
>> change the existing behavior marginally, would be to calculate the 
>> height two times, once at EOB and once at EOB-1.
>
> This assumes that there's no overlay strings at EOB-1?  Why would we 
> assume something like that?  It again narrows the set of use cases which 
> will be handled properly.
>

The problem happens when completion candidates (with icomplete, ido, and I 
guess others are doing the same) are displayed after the point, with an 
overlay at EOB.  If you think this is a too narrow set of use cases, I 
guess the best thing to do is to let applications choose what to do with a 
start_display_at_beginning_of_minibuffer variable, to let applications 
override what "seems desirable generally".  Setting a variable in 
minibuffer-setup-hook is easy.

>
> It also seems to assume that the prompt (which ends at EOB) is much 
> shorter than the overlay string displayed beyond EOB.  But this is not 
> guaranteed: it could be the other way around, in which case the proposed 
> changes will not show the most important part of the mini-window's 
> display.
>

Did you look at what the code currently does?  With emacs -q, M-x 
icomplete-mode, (setq icomplete-separator "\n"), C-x C-f, you have a 
mini-window with a blinking cursor at the top left, and each time you 
enter a directory its name disappears.  This behavior is considered not 
user-friendly, so much that those who implement completion mechanisms use 
complicated workarounds to avoid it.

>
> My suggestion is to go back to the "start display at BOB" assertion 
> (which is not true in general), and try to find a more general/more 
> accurate one.  For example: would it be okay to start the display at the 
> beginning of the screen line where we end up after 
> move_it_vertically_backward returns?
>

IMO, no, this would not be okay, at least not for icomplete/ido/...  What 
users expect is to see the prompt and what they have entered so far until 
they press RET.  Even if that means displaying one less completion 
candidate at the end of the list.  (When use complete a file name or a 
command in a terminal, the prompt and what you have typed so far does not 
disappear.)

>
> This way, if the prompt is very long, we will start in its middle (at 
> the beginning of one of the continuation lines used to display the 
> prompt), but we will show as much of the overlay string as possible. 
> This strategy will also handle minibuffer prompts that don't use overlay 
> strings at all better than if we start at BOB.
>

I see what you mean.  So I propose to simply let applications/users choose 
what they want in each case with a 
start_display_at_beginning_of_minibuffer variable.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Gregory Heytings <ghe@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 21 Sep 2020 15:27:01 +0000
Resent-Message-ID: <handler.43519.B43519.160070199315996 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: monnier@HIDDEN, 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.160070199315996
          (code B ref 43519); Mon, 21 Sep 2020 15:27:01 +0000
Received: (at 43519) by debbugs.gnu.org; 21 Sep 2020 15:26:33 +0000
Received: from localhost ([127.0.0.1]:55846 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kKNi4-00049p-ND
	for submit <at> debbugs.gnu.org; Mon, 21 Sep 2020 11:26:33 -0400
Received: from mx.sdf.org ([205.166.94.24]:64122)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ghe@HIDDEN>) id 1kKNi1-00049d-7k
 for 43519 <at> debbugs.gnu.org; Mon, 21 Sep 2020 11:26:31 -0400
Received: from sdf.org (IDENT:ghe@HIDDEN [205.166.94.9])
 by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 08LFQSjm021411
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO);
 Mon, 21 Sep 2020 15:26:28 GMT
Received: (from ghe@localhost)
 by sdf.org (8.15.2/8.12.8/Submit) id 08LFQgsD003719;
 Mon, 21 Sep 2020 15:26:42 GMT
Date: Mon, 21 Sep 2020 15:26:25 +0000
From: Gregory Heytings <ghe@HIDDEN>
In-Reply-To: <83pn6fxk7f.fsf@HIDDEN>
Message-ID: <alpine.NEB.2.22.394.2009211703120453.13012@HIDDEN>
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009202237350453.31246@HIDDEN>
 <83363bz0r0.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009211603470453.9454@HIDDEN>
 <83pn6fxk7f.fsf@HIDDEN>
User-Agent: Alpine 2.22 (NEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


>
> But with long enough prompt, you can have _none_ of the candidates 
> displayed.
>

With a long enough prompt *and* a small enough mini-window, yes, this can 
happen.

>
> "Unlikely to happen" is not a good guideline for making changes in the 
> display code, IME.  Guess what? most of the things I considered 
> "unlikely" did happen eventually.
>

I'm not saying it will not happen, in fact it's easy to make it happen. 
Just create a long enough directory name, (setq max-mini-window-height 1), 
and enter that directory.  I'm just saying that the likelihook it will 
happen is practice is much, much smaller than the other case, where users 
want to see the prompt, what they have typed so far, and some completion 
candidates after the point.

>
> So I prefer a more generally correct solution, especially when it's not 
> hard to implement.
>

I fear it will be hard to find a "more generally correct solution".  In 
fact, it's a correct solution, so you are looking for a "more generally 
_more_ correct solution" ;-)  BTW, the current solution does not claim to 
be a correct solution, but only that it "seems desirable generally".

>> In that case you start with a blinking cursor at the top left of the 
>> minibuffer, without any indication of what you are doing or should do.
>
> Are you talking about what we see today?
>

Yes.

>
> I'm not arguing to leave it unchanged, I'm talking about what would be 
> the better solution, and starting always at BOB sounds sub-optimal to 
> me.
>

I can't think of a better solution.

>
> The solution I proposed in my other message (assuming that it is 
> accepted) is more general, I think.
>

If you mean "to start the display at the beginning of the screen line 
where we end up after move_it_vertically_backward returns", it is IMO 
worse.  At least with the usecase of completion candidates in mind, it is 
better to have one or two less candidates at the bottom of the 
mini-window, and the prompt displayed at the top of the mini-window.

>
> It also covers "corner cases" which you are willing to disregard.
>

I do not disregard them.  I tested them.  The worst that could happen is 
that, in some rare cases, no completion candidates would be displayed in 
the mini-window, in which case the user can hit TAB and they will be 
displayed in a *Completions* buffer.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 21 Sep 2020 15:34:01 +0000
Resent-Message-ID: <handler.43519.B43519.160070243825036 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Gregory Heytings <ghe@HIDDEN>
Cc: monnier@HIDDEN, 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.160070243825036
          (code B ref 43519); Mon, 21 Sep 2020 15:34:01 +0000
Received: (at 43519) by debbugs.gnu.org; 21 Sep 2020 15:33:58 +0000
Received: from localhost ([127.0.0.1]:55862 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kKNpF-0006Vk-Pq
	for submit <at> debbugs.gnu.org; Mon, 21 Sep 2020 11:33:58 -0400
Received: from eggs.gnu.org ([209.51.188.92]:33104)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1kKNpD-0006VV-0V
 for 43519 <at> debbugs.gnu.org; Mon, 21 Sep 2020 11:33:55 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:59178)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1kKNp6-0005tT-CJ; Mon, 21 Sep 2020 11:33:48 -0400
Received: from [176.228.60.248] (port=3875 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1kKNp2-00076b-Rg; Mon, 21 Sep 2020 11:33:47 -0400
Date: Mon, 21 Sep 2020 18:33:46 +0300
Message-Id: <83mu1jxhyd.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <alpine.NEB.2.22.394.2009211633090453.11632@HIDDEN>
 (message from Gregory Heytings on Mon, 21 Sep 2020 15:02:31 +0000)
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009202237350453.31246@HIDDEN>
 <alpine.NEB.2.22.394.2009202327470453.3406@HIDDEN>
 <alpine.NEB.2.22.394.2009210836270453.4535@HIDDEN>
 <83tuvrxlho.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009211633090453.11632@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Mon, 21 Sep 2020 15:02:31 +0000
> From: Gregory Heytings <ghe@HIDDEN>
> cc: monnier@HIDDEN, 43519 <at> debbugs.gnu.org
> 
> > For example: would it be okay to start the display at the 
> > beginning of the screen line where we end up after 
> > move_it_vertically_backward returns?
> 
> IMO, no, this would not be okay, at least not for icomplete/ido/...

In that case, what I propose will have exactly the same effect as
setting window-start at BOB.  So I don't understand why you say that
this will not do.

Stefan, what do you think about the above proposal?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 21 Sep 2020 15:40:02 +0000
Resent-Message-ID: <handler.43519.B43519.160070278625690 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Gregory Heytings <ghe@HIDDEN>
Cc: monnier@HIDDEN, 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.160070278625690
          (code B ref 43519); Mon, 21 Sep 2020 15:40:02 +0000
Received: (at 43519) by debbugs.gnu.org; 21 Sep 2020 15:39:46 +0000
Received: from localhost ([127.0.0.1]:55889 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kKNus-0006gI-H8
	for submit <at> debbugs.gnu.org; Mon, 21 Sep 2020 11:39:46 -0400
Received: from eggs.gnu.org ([209.51.188.92]:34526)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1kKNuq-0006g5-Os
 for 43519 <at> debbugs.gnu.org; Mon, 21 Sep 2020 11:39:45 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:59395)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1kKNuk-0006vs-Vi; Mon, 21 Sep 2020 11:39:39 -0400
Received: from [176.228.60.248] (port=4234 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1kKNug-0007bt-JR; Mon, 21 Sep 2020 11:39:36 -0400
Date: Mon, 21 Sep 2020 18:39:36 +0300
Message-Id: <83k0wnxhon.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <alpine.NEB.2.22.394.2009211703120453.13012@HIDDEN>
 (message from Gregory Heytings on Mon, 21 Sep 2020 15:26:25 +0000)
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009202237350453.31246@HIDDEN>
 <83363bz0r0.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009211603470453.9454@HIDDEN>
 <83pn6fxk7f.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009211703120453.13012@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Mon, 21 Sep 2020 15:26:25 +0000
> From: Gregory Heytings <ghe@HIDDEN>
> cc: monnier@HIDDEN, 43519 <at> debbugs.gnu.org
> 
> > The solution I proposed in my other message (assuming that it is 
> > accepted) is more general, I think.
> 
> If you mean "to start the display at the beginning of the screen line 
> where we end up after move_it_vertically_backward returns", it is IMO 
> worse.

I think you misunderstand my proposal, because the beginning of the
screen line where we end up in the use case we are discussing is the
BOB.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Gregory Heytings <ghe@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 21 Sep 2020 15:45:02 +0000
Resent-Message-ID: <handler.43519.B43519.160070306226103 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: monnier@HIDDEN, 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.160070306226103
          (code B ref 43519); Mon, 21 Sep 2020 15:45:02 +0000
Received: (at 43519) by debbugs.gnu.org; 21 Sep 2020 15:44:22 +0000
Received: from localhost ([127.0.0.1]:55893 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kKNzK-0006mw-5S
	for submit <at> debbugs.gnu.org; Mon, 21 Sep 2020 11:44:22 -0400
Received: from mx.sdf.org ([205.166.94.24]:63203)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ghe@HIDDEN>) id 1kKNzH-0006mo-Sv
 for 43519 <at> debbugs.gnu.org; Mon, 21 Sep 2020 11:44:21 -0400
Received: from sdf.org (IDENT:ghe@HIDDEN [205.166.94.9])
 by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 08LFiIAX020185
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO);
 Mon, 21 Sep 2020 15:44:19 GMT
Received: (from ghe@localhost)
 by sdf.org (8.15.2/8.12.8/Submit) id 08LFiY2E020369;
 Mon, 21 Sep 2020 15:44:34 GMT
Date: Mon, 21 Sep 2020 15:44:16 +0000
From: Gregory Heytings <ghe@HIDDEN>
In-Reply-To: <83mu1jxhyd.fsf@HIDDEN>
Message-ID: <alpine.NEB.2.22.394.2009211734460453.15638@HIDDEN>
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009202237350453.31246@HIDDEN>
 <alpine.NEB.2.22.394.2009202327470453.3406@HIDDEN>
 <alpine.NEB.2.22.394.2009210836270453.4535@HIDDEN>
 <83tuvrxlho.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009211633090453.11632@HIDDEN>
 <83mu1jxhyd.fsf@HIDDEN>
User-Agent: Alpine 2.22 (NEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


>>> For example: would it be okay to start the display at the beginning of 
>>> the screen line where we end up after move_it_vertically_backward 
>>> returns?
>>
>> IMO, no, this would not be okay, at least not for icomplete/ido/...
>
> In that case, what I propose will have exactly the same effect as 
> setting window-start at BOB.  So I don't understand why you say that 
> this will not do.
>

Perhaps I misunderstood something, but for me "start the display at the 
beginning of the screen line where we end up after 
move_it_vertically_backward" would mean that if the prompt and the user 
input so far needs more than one line, only the last line would be 
displayed.  So instead of having, say,

Find file: <user input>
<user input>|
<completion candidates>

(where | represents the cursor) we would only have:

<user input>|
<completion candidates>

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Gregory Heytings <ghe@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 21 Sep 2020 16:01:01 +0000
Resent-Message-ID: <handler.43519.B43519.16007040103404 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: monnier@HIDDEN, 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.16007040103404
          (code B ref 43519); Mon, 21 Sep 2020 16:01:01 +0000
Received: (at 43519) by debbugs.gnu.org; 21 Sep 2020 16:00:10 +0000
Received: from localhost ([127.0.0.1]:55939 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kKOEc-0000sq-5Y
	for submit <at> debbugs.gnu.org; Mon, 21 Sep 2020 12:00:10 -0400
Received: from mx.sdf.org ([205.166.94.24]:61898)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ghe@HIDDEN>) id 1kKOEX-0000re-CY
 for 43519 <at> debbugs.gnu.org; Mon, 21 Sep 2020 12:00:08 -0400
Received: from sdf.org (IDENT:ghe@HIDDEN [205.166.94.9])
 by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 08LG033d018409
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO);
 Mon, 21 Sep 2020 16:00:03 GMT
Received: (from ghe@localhost)
 by sdf.org (8.15.2/8.12.8/Submit) id 08LG0Ir6012025;
 Mon, 21 Sep 2020 16:00:18 GMT
Date: Mon, 21 Sep 2020 16:00:01 +0000
From: Gregory Heytings <ghe@HIDDEN>
In-Reply-To: <83k0wnxhon.fsf@HIDDEN>
Message-ID: <alpine.NEB.2.22.394.2009211748510453.16175@HIDDEN>
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009202237350453.31246@HIDDEN>
 <83363bz0r0.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009211603470453.9454@HIDDEN>
 <83pn6fxk7f.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009211703120453.13012@HIDDEN>
 <83k0wnxhon.fsf@HIDDEN>
User-Agent: Alpine 2.22 (NEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


>>> The solution I proposed in my other message (assuming that it is 
>>> accepted) is more general, I think.
>>
>> If you mean "to start the display at the beginning of the screen line 
>> where we end up after move_it_vertically_backward returns", it is IMO 
>> worse.
>
> I think you misunderstand my proposal, because the beginning of the 
> screen line where we end up in the use case we are discussing is the 
> BOB.
>

I'm not sure they are, but I'm not an expert.  If they are, then of course 
your proposal would be okay.

The purpose of the discussion (AFAIU) is to introduce a change to make it 
possible for icomplete/ido/... to put a too long overlay at EOB (with say 
two or three more candidates than can be displayed in the mini-window), in 
such a way that the prompt will always be displayed, and the last part of 
the overlay will not.  What happens with your proposal when 
max-mini-window-height is 10, and the overlay needs 13 lines?  What 
happens when max-mini-window-height, the overlay needs 10 lines, and the 
prompt and user input so far need two lines?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 21 Sep 2020 16:11:01 +0000
Resent-Message-ID: <handler.43519.B43519.16007046284521 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Gregory Heytings <ghe@HIDDEN>
Cc: monnier@HIDDEN, 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.16007046284521
          (code B ref 43519); Mon, 21 Sep 2020 16:11:01 +0000
Received: (at 43519) by debbugs.gnu.org; 21 Sep 2020 16:10:28 +0000
Received: from localhost ([127.0.0.1]:55968 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kKOOZ-0001Aq-Q7
	for submit <at> debbugs.gnu.org; Mon, 21 Sep 2020 12:10:28 -0400
Received: from eggs.gnu.org ([209.51.188.92]:43576)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1kKOOW-0001Ac-6x
 for 43519 <at> debbugs.gnu.org; Mon, 21 Sep 2020 12:10:26 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:60048)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1kKOOQ-0003nA-Ns; Mon, 21 Sep 2020 12:10:18 -0400
Received: from [176.228.60.248] (port=2259 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1kKOOO-0003NE-G6; Mon, 21 Sep 2020 12:10:17 -0400
Date: Mon, 21 Sep 2020 19:10:18 +0300
Message-Id: <83imc7xg9h.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <alpine.NEB.2.22.394.2009211734460453.15638@HIDDEN>
 (message from Gregory Heytings on Mon, 21 Sep 2020 15:44:16 +0000)
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009202237350453.31246@HIDDEN>
 <alpine.NEB.2.22.394.2009202327470453.3406@HIDDEN>
 <alpine.NEB.2.22.394.2009210836270453.4535@HIDDEN>
 <83tuvrxlho.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009211633090453.11632@HIDDEN>
 <83mu1jxhyd.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009211734460453.15638@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Mon, 21 Sep 2020 15:44:16 +0000
> From: Gregory Heytings <ghe@HIDDEN>
> cc: monnier@HIDDEN, 43519 <at> debbugs.gnu.org
> 
> Perhaps I misunderstood something, but for me "start the display at the 
> beginning of the screen line where we end up after 
> move_it_vertically_backward" would mean that if the prompt and the user 
> input so far needs more than one line, only the last line would be 
> displayed.  So instead of having, say,
> 
> Find file: <user input>
> <user input>|
> <completion candidates>
> 
> (where | represents the cursor) we would only have:
> 
> <user input>|
> <completion candidates>

Yes.

This bug was filed to request that Emacs behaves with overlay-string in
the minibuffer prompt the same as with regular buffer text.  What I
propose will do that, or as close as possible to it.  By contrast, you
seem to suggest a change in the current behavior for buffer text as
well.  That may or may not be a good idea, but it's a separate issue,
so should be discussed separately (and in that separate discussion I
will generally be opposed to the change you are proposing, because we
had the current behavior for many years, and so changes like the one
you propose run serious risk of breaking expectations of some package
out there).

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Gregory Heytings <ghe@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 21 Sep 2020 16:28:02 +0000
Resent-Message-ID: <handler.43519.B43519.16007056796182 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: monnier@HIDDEN, 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.16007056796182
          (code B ref 43519); Mon, 21 Sep 2020 16:28:02 +0000
Received: (at 43519) by debbugs.gnu.org; 21 Sep 2020 16:27:59 +0000
Received: from localhost ([127.0.0.1]:55986 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kKOfX-0001be-GI
	for submit <at> debbugs.gnu.org; Mon, 21 Sep 2020 12:27:59 -0400
Received: from mx.sdf.org ([205.166.94.24]:60227)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ghe@HIDDEN>) id 1kKOfT-0001bU-Ie
 for 43519 <at> debbugs.gnu.org; Mon, 21 Sep 2020 12:27:58 -0400
Received: from sdf.org (IDENT:ghe@HIDDEN [205.166.94.9])
 by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 08LGRsR7017202
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO);
 Mon, 21 Sep 2020 16:27:54 GMT
Received: (from ghe@localhost)
 by sdf.org (8.15.2/8.12.8/Submit) id 08LGS9xu005629;
 Mon, 21 Sep 2020 16:28:09 GMT
Date: Mon, 21 Sep 2020 16:27:51 +0000
From: Gregory Heytings <ghe@HIDDEN>
In-Reply-To: <83imc7xg9h.fsf@HIDDEN>
Message-ID: <alpine.NEB.2.22.394.2009211811480453.18585@HIDDEN>
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009202237350453.31246@HIDDEN>
 <alpine.NEB.2.22.394.2009202327470453.3406@HIDDEN>
 <alpine.NEB.2.22.394.2009210836270453.4535@HIDDEN>
 <83tuvrxlho.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009211633090453.11632@HIDDEN>
 <83mu1jxhyd.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009211734460453.15638@HIDDEN>
 <83imc7xg9h.fsf@HIDDEN>
User-Agent: Alpine 2.22 (NEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


>> Perhaps I misunderstood something, but for me "start the display at the 
>> beginning of the screen line where we end up after 
>> move_it_vertically_backward" would mean that if the prompt and the user 
>> input so far needs more than one line, only the last line would be 
>> displayed.  So instead of having, say,
>>
>> Find file: <user input>
>> <user input>|
>> <completion candidates>
>>
>> (where | represents the cursor) we would only have:
>>
>> <user input>|
>> <completion candidates>
>
> Yes.
>
> This bug was filed to request that Emacs behaves with overlay-string in 
> the minibuffer prompt the same as with regular buffer text.
>

Hmmm...  no, this bug was filed after a discussion on emacs-devel (about 
implementing vertical icomplete), and the problem is clearly stated by 
Stefan: the prompt and user input so far disappear.

>
> What I propose will do that, or as close as possible to it.  By 
> contrast, you seem to suggest a change in the current behavior for 
> buffer text as well.
>

Which is why my proposal is to not break anything, but only to give 
applications the control of how what they insert in the minibuffer is 
displayed.  A start_display_at_beginning_of_minibuffer variable that would 
be reset in read_minibuf() and that an application could set in 
minibuffer-setup-hook.  I don't understand why you would be opposed to 
such a change.

>
> That may or may not be a good idea, but it's a separate issue, so should 
> be discussed separately
>

It's _not_ a separate issue, it's the issue at hand.

>
> (and in that separate discussion I will generally be opposed to the 
> change you are proposing, because we had the current behavior for many 
> years, and so changes like the one you propose run serious risk of 
> breaking expectations of some package out there).
>

Why would a change that does not change Emacs' behavior in any way except 
if the user requests it "run serious risk of breaking expectations of some 
package out there"?  It only gives application writers the freedom to 
decide what Emacs should do, which is IMO a good thing in general.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 21 Sep 2020 17:26:02 +0000
Resent-Message-ID: <handler.43519.B43519.160070911311804 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.160070911311804
          (code B ref 43519); Mon, 21 Sep 2020 17:26:02 +0000
Received: (at 43519) by debbugs.gnu.org; 21 Sep 2020 17:25:13 +0000
Received: from localhost ([127.0.0.1]:56068 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kKPYv-00034K-GK
	for submit <at> debbugs.gnu.org; Mon, 21 Sep 2020 13:25:13 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:10646)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1kKPYs-000343-CZ
 for 43519 <at> debbugs.gnu.org; Mon, 21 Sep 2020 13:25:12 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id B1E5C100234;
 Mon, 21 Sep 2020 13:25:04 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0B02B100019;
 Mon, 21 Sep 2020 13:25:03 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1600709103;
 bh=yJih/gA+Ovs6mu/7mobzZh+zhKvrwOA5eyvSQBgOzsk=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=XABaML4V5xL1/shuKcSYd9xYxHaHvdORs52pgWfyAP3OtUvICsK1MrSSZTFVnHHQ4
 ee1SNsnuVVzYizSSbyyfo2+cHs/rW2YWrbdpBpZM7IoJEdCbQfqiSa67dJ2lEYe/kK
 DveC2VAlbdjRvSL+6RVBx0TfjZnc528TsUQ0J6h8CGVvDdOTu1Jv7suWDcKa2p8Pkr
 P9KHbjg6jGMNbge7az+g/OvzwHYgG55ewQyz3F+InX4KG7NtDphb48MElSpDAnMTTz
 AlFQdQhVm+ouLo127LRbbrITNQoMGr+c82z4isgWXD1inaoejCHu2eTcKF5+PCNdzl
 dW1lV3fWUJoJQ==
Received: from alfajor (unknown [45.72.232.131])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id AD691120264;
 Mon, 21 Sep 2020 13:25:02 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwvwo0n2hgh.fsf-monnier+emacs@HIDDEN>
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
 <jwvd02g5bnp.fsf-monnier+emacs@HIDDEN> <83y2l3xm15.fsf@HIDDEN>
Date: Mon, 21 Sep 2020 13:25:01 -0400
In-Reply-To: <83y2l3xm15.fsf@HIDDEN> (Eli Zaretskii's message of "Mon, 21 Sep
 2020 17:05:42 +0300")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.050 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> 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?
> Because this way we have no control on where the mini-window's display
> will start, and consequently what will be visible in the mini-window.

Indeed, then we'll just rely on the "generic" behavior, which is
admittedly not focused on single-line (or few lines) windows, but at
least in the current case it works better (and simplifies the code
slightly).

> In particular, if point is at EOB, redisplay could (and normally does)
> decide not to position point on the last screen line of the window,
> which means we may have some of the text not visible for no good
> reason -- not a good thing when user interaction is concerned.

Not sure I understand what you mean.
If point is at EOB, redisplay will make sure EOB is visible.

Or do you mean a situation like:
- minibuffer holds "foo\n"
- the mini window is a single line
- point is at EOB
In which case we'd end up displaying the empty line instead of display "foo"?

AFAICT our ad-hoc scrolling code gives the same result as the generic
scrolling code in that case.

I've been trying out the patch below and haven't bumped into any
surprising behavior yet, but admittedly, I probably lack creativity.

> More generally, since the mini-window is usually small and user
> interaction requires to make sure the user sees the important parts of
> the buffer text (if not all of it), we want tighter control on what
> will end up on display, and the way to do that is via setting
> window-start.

That makes sense in general, but I'm curious to see what are the
concrete cases where our "generic" scrolling logic leads to worse
behavior than the ad-hoc one used here.

So far the patch below fixed the original problem and I haven't been
able to see any regression yet.

>>     (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.
> Disabling resize-mini-windows means the mini-window is not resized at
> all as part of redisplay.

Yes, of course, I was just using it to illustrate what happens when we
don't use the ad-hoc scrolling code from resize_mini_window in the case
where there is in practice no resizing anyway.

> And besides, this is a user option, so having some code disregard it
> is unfriendly, to say the least, even if we do that temporarily.

Oh yes,


        Stefan


diff --git a/src/xdisp.c b/src/xdisp.c
index dfcb1d73e4..b25aa07f1f 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -11885,14 +11885,18 @@ resize_mini_window (struct window *w, bool exact_p)
       if (height > max_height)
 	{
 	  height = (max_height / unit) * unit;
-	  init_iterator (&it, w, ZV, ZV_BYTE, NULL, DEFAULT_FACE_ID);
-	  move_it_vertically_backward (&it, height - unit);
-	  start = it.current.pos;
+	  /* bug#43519: Let the redisplay choose the window start!
+           *
+           * init_iterator (&it, w, ZV, ZV_BYTE, NULL, DEFAULT_FACE_ID);
+	   * move_it_vertically_backward (&it, height - unit);
+	   * start = it.current.pos; */
 	}
       else
-	SET_TEXT_POS (start, BEGV, BEGV_BYTE);
+	{
+	  SET_TEXT_POS (start, BEGV, BEGV_BYTE);
 
-      SET_MARKER_FROM_TEXT_POS (w->start, start);
+          SET_MARKER_FROM_TEXT_POS (w->start, start);
+        }
 
       if (EQ (Vresize_mini_windows, Qgrow_only))
 	{

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 21 Sep 2020 17:30:02 +0000
Resent-Message-ID: <handler.43519.B43519.160070934812155 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: Gregory Heytings <ghe@HIDDEN>, 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.160070934812155
          (code B ref 43519); Mon, 21 Sep 2020 17:30:02 +0000
Received: (at 43519) by debbugs.gnu.org; 21 Sep 2020 17:29:08 +0000
Received: from localhost ([127.0.0.1]:56077 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kKPci-00039z-EC
	for submit <at> debbugs.gnu.org; Mon, 21 Sep 2020 13:29:08 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:25695)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1kKPch-00039a-AF
 for 43519 <at> debbugs.gnu.org; Mon, 21 Sep 2020 13:29:07 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0FEE7100234;
 Mon, 21 Sep 2020 13:29:02 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 6F776100019;
 Mon, 21 Sep 2020 13:29:00 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1600709340;
 bh=4eb9i1iIcEGr0Ahx5G49/vPIT9Ojf8/ctjY06cxaJeQ=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=lWX6kYRR3zhYXVjMvYmn57BTbN46cxgLUTBtZ45QG1C7pAAzOcG7/CNE9z8W9jHgG
 3sfQ5SaYn3zybotLERSNWGFfc75A/lSlHFQc3Dd64C3hgTEE5szE14lA0s5bGScsJM
 sE/iyF9M0GUIvGlRZgAwpii7MJ7FgdGJwOCM/T54ZqieLcW70/aABdSnHLtQNkoLOo
 bz9HSwN+sa9R5DeRNzrO5VLf8J+yjWfBL1JNCgK2duZ8f6Om8lEYZVN0KT3q4UPaGw
 ltoo8U09dTOHZT/DvTc2OcDdrPg5i2gN9n1nt4fSfcWc7M3l1m4coPuZb0mvBe5Wj3
 z3fJt6o4fVXjQ==
Received: from alfajor (unknown [45.72.232.131])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 43F2E1202FB;
 Mon, 21 Sep 2020 13:29:00 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwvlfh32g8q.fsf-monnier+emacs@HIDDEN>
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009202237350453.31246@HIDDEN>
 <alpine.NEB.2.22.394.2009202327470453.3406@HIDDEN>
 <alpine.NEB.2.22.394.2009210836270453.4535@HIDDEN>
 <83tuvrxlho.fsf@HIDDEN>
Date: Mon, 21 Sep 2020 13:28:59 -0400
In-Reply-To: <83tuvrxlho.fsf@HIDDEN> (Eli Zaretskii's message of "Mon, 21 Sep
 2020 17:17:23 +0300")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.050 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Eli Zaretskii [2020-09-21 17:17:23] wrote:
> For example: would it be okay to start the display at
> the beginning of the screen line where we end up after
> move_it_vertically_backward returns?

Sounds reasonable.  Do we have something like tests (or at least a list
of recipes to try) so we can catch regressions?  It seems this part of
the code is trying to satisfy needs which aren't clearly expressed
anywhere, so while this suggestion may sound good to me (just like the
patch I just sent), I'm afraid it will bring back other problems.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 21 Sep 2020 17:31:02 +0000
Resent-Message-ID: <handler.43519.B43519.160070945112408 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Gregory Heytings <ghe@HIDDEN>
Cc: monnier@HIDDEN, 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.160070945112408
          (code B ref 43519); Mon, 21 Sep 2020 17:31:02 +0000
Received: (at 43519) by debbugs.gnu.org; 21 Sep 2020 17:30:51 +0000
Received: from localhost ([127.0.0.1]:56092 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kKPeM-0003E4-Pm
	for submit <at> debbugs.gnu.org; Mon, 21 Sep 2020 13:30:51 -0400
Received: from eggs.gnu.org ([209.51.188.92]:36960)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1kKPeK-0003Ds-TS
 for 43519 <at> debbugs.gnu.org; Mon, 21 Sep 2020 13:30:49 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:33357)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1kKPeF-0007O9-Hx; Mon, 21 Sep 2020 13:30:43 -0400
Received: from [176.228.60.248] (port=3189 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1kKPeB-0006dj-Jp; Mon, 21 Sep 2020 13:30:41 -0400
Date: Mon, 21 Sep 2020 20:30:40 +0300
Message-Id: <83ft7bxcjj.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <alpine.NEB.2.22.394.2009211811480453.18585@HIDDEN>
 (message from Gregory Heytings on Mon, 21 Sep 2020 16:27:51 +0000)
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009202237350453.31246@HIDDEN>
 <alpine.NEB.2.22.394.2009202327470453.3406@HIDDEN>
 <alpine.NEB.2.22.394.2009210836270453.4535@HIDDEN>
 <83tuvrxlho.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009211633090453.11632@HIDDEN>
 <83mu1jxhyd.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009211734460453.15638@HIDDEN>
 <83imc7xg9h.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009211811480453.18585@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Mon, 21 Sep 2020 16:27:51 +0000
> From: Gregory Heytings <ghe@HIDDEN>
> cc: monnier@HIDDEN, 43519 <at> debbugs.gnu.org
> 
> > This bug was filed to request that Emacs behaves with overlay-string in 
> > the minibuffer prompt the same as with regular buffer text.
> 
> Hmmm...  no, this bug was filed after a discussion on emacs-devel (about 
> implementing vertical icomplete), and the problem is clearly stated by 
> Stefan: the prompt and user input so far disappear.

That's not my reading of the main argument, posted by Stefan in

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43519#17

Some quotes:

  I used `icomplete-mode` only as a vehicle to show the underlying
  behavior with a short recipe which exhibits a real-life problem.
  [...]
  This performs "display of text after point" in 2 different ways:
  - first by `insert`.
  - then with an overlay.
  The visual rendering of the text is the same, with the cursor at the
  same place.  When we do it with `insert` there is no horizontal
  scrolling, but when we do it with an overlay the text gets scrolled so
  the cursor is at `window-start`.

  `icomplete` needs the behavior to be the same as with `insert`, but it
  prefers to use an overlay to avoid some undesirable side-effects of
  modifying the actual text.

  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?

My summary of the problem raised by Stefan:

  . icomplete is just an example that exhibits a more general issue
  . the more general issue is that the display after resizing the
    mini-window is different depending on whether it uses plain buffer
    text or an after-string overlay at EOB

If you use Stefan's recipe, but make the prompt much longer, like
this:

    (minibuffer-with-setup-hook
        (lambda ()
          (insert "hello")
          (let ((ol (make-overlay (point) (point)))
                (max-mini-window-height 1)
                (text "askdjfhaklsjdfhlkasjdfhklasdhflkasdhflkajsdhflkashdfkljahsdlfkjahsdlfkjhasldkfhalskdjfhalskdfhlaksdhfklasdhflkasdhflkasdhflkajsdhklajsdgh"))
            (save-excursion (insert text))
            (sit-for 2)
            (delete-region (point) (point-max))
            (put-text-property 0 1 'cursor t text)
            (overlay-put ol 'after-string text)
            (sit-for 2)
            (delete-overlay ol)))
      (read-string "totototototototototototototototototototototototototototototototototototototototototototototototototototo: "))

then in the 1st ("insert text") part of the recipe you will see only
the last part of the prompt.  Which is the long-standing behavior of
resizing mini-windows: if the mini-window cannot be enlarged enough to
show the entire text in it, we show its last part.

Stefan asked for the same behavior when an overlay with after-string
is used.  My suggestion (I hope) will do what he asks, or approximate
that as well as I think is possible under the current design of the
display code.

> Which is why my proposal is to not break anything, but only to give 
> applications the control of how what they insert in the minibuffer is 
> displayed.  A start_display_at_beginning_of_minibuffer variable that would 
> be reset in read_minibuf() and that an application could set in 
> minibuffer-setup-hook.  I don't understand why you would be opposed to 
> such a change.

Because it changes a long-standing behavior with inserting normal text
into the minibuffer.

> > That may or may not be a good idea, but it's a separate issue, so should 
> > be discussed separately
> 
> It's _not_ a separate issue, it's the issue at hand.

I disagree, and I explained above why.

> > (and in that separate discussion I will generally be opposed to the 
> > change you are proposing, because we had the current behavior for many 
> > years, and so changes like the one you propose run serious risk of 
> > breaking expectations of some package out there).
> >
> 
> Why would a change that does not change Emacs' behavior in any way except 
> if the user requests it "run serious risk of breaking expectations of some 
> package out there"?

This is not the user, this is a Lisp program that will do it.  The
behavior will change in that the user will be shown only the first
part of the text, as opposed to the last part we were showing until
now.  Maybe such a change in behavior is desirable (I'm not sure, and
I don't yet have a clear idea how will Lisp programs decide which
behavior to request), but it's a separate issue.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 21 Sep 2020 17:46:02 +0000
Resent-Message-ID: <handler.43519.B43519.160071031513682 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.160071031513682
          (code B ref 43519); Mon, 21 Sep 2020 17:46:02 +0000
Received: (at 43519) by debbugs.gnu.org; 21 Sep 2020 17:45:15 +0000
Received: from localhost ([127.0.0.1]:56097 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kKPsJ-0003YZ-7U
	for submit <at> debbugs.gnu.org; Mon, 21 Sep 2020 13:45:15 -0400
Received: from eggs.gnu.org ([209.51.188.92]:40156)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1kKPsF-0003YI-Ip
 for 43519 <at> debbugs.gnu.org; Mon, 21 Sep 2020 13:45:13 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:33502)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1kKPs9-0000fD-Tf; Mon, 21 Sep 2020 13:45:05 -0400
Received: from [176.228.60.248] (port=4065 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1kKPs9-0007L4-47; Mon, 21 Sep 2020 13:45:05 -0400
Date: Mon, 21 Sep 2020 20:45:07 +0300
Message-Id: <83eemvxbvg.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <jwvwo0n2hgh.fsf-monnier+emacs@HIDDEN> (message from Stefan
 Monnier on Mon, 21 Sep 2020 13:25:01 -0400)
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
 <jwvd02g5bnp.fsf-monnier+emacs@HIDDEN> <83y2l3xm15.fsf@HIDDEN>
 <jwvwo0n2hgh.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: 43519 <at> debbugs.gnu.org
> Date: Mon, 21 Sep 2020 13:25:01 -0400
> 
> >> 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?
> > Because this way we have no control on where the mini-window's display
> > will start, and consequently what will be visible in the mini-window.
> 
> Indeed, then we'll just rely on the "generic" behavior, which is
> admittedly not focused on single-line (or few lines) windows, but at
> least in the current case it works better (and simplifies the code
> slightly).

I believe the "works better" part is only guaranteed if
max-mini-window-height is 1.

> > In particular, if point is at EOB, redisplay could (and normally does)
> > decide not to position point on the last screen line of the window,
> > which means we may have some of the text not visible for no good
> > reason -- not a good thing when user interaction is concerned.
> 
> Not sure I understand what you mean.
> If point is at EOB, redisplay will make sure EOB is visible.
> 
> Or do you mean a situation like:
> - minibuffer holds "foo\n"
> - the mini window is a single line
> - point is at EOB
> In which case we'd end up displaying the empty line instead of display "foo"?

Something like that.  More generally, assume the text to be displayed
in the mini-window is

   111111111111111111
   2222222222222222222222
   33333333333333333333
   444444444444444444444

With point in the 4th line and max-mini-window-height = 4, there's no
guarantee that we will see all the 4 lines, we could see just 3 and an
empty 4th one.  Which means the user is shown only part of the stuff
for no good reason.

> AFAICT our ad-hoc scrolling code gives the same result as the generic
> scrolling code in that case.

Not sure what ad-hoc scrolling code you allude to here.  If you mean
what resize_mini_window does, then it doesn't really scroll, it just
instructs redisplay to use a particular buffer position as the
window-start; if that position makes point visible, redisplay will
comply, and we get what we wanted: we show in the mini-window what we
want to show, instead of leaving that to redisplay's whims.

> I've been trying out the patch below and haven't bumped into any
> surprising behavior yet, but admittedly, I probably lack creativity.

IOW, you leave it entirely to the generic window-display code to
select window-start based just on the value of point?  And only when
the mini-window cannot be enlarged enough?  I wouldn't.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 21 Sep 2020 17:48:02 +0000
Resent-Message-ID: <handler.43519.B43519.160071043413909 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: ghe@HIDDEN, 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.160071043413909
          (code B ref 43519); Mon, 21 Sep 2020 17:48:02 +0000
Received: (at 43519) by debbugs.gnu.org; 21 Sep 2020 17:47:14 +0000
Received: from localhost ([127.0.0.1]:56105 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kKPuD-0003cH-Uj
	for submit <at> debbugs.gnu.org; Mon, 21 Sep 2020 13:47:14 -0400
Received: from eggs.gnu.org ([209.51.188.92]:40534)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1kKPuC-0003c2-L4
 for 43519 <at> debbugs.gnu.org; Mon, 21 Sep 2020 13:47:13 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:33523)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1kKPu7-0000yh-BW; Mon, 21 Sep 2020 13:47:07 -0400
Received: from [176.228.60.248] (port=4191 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1kKPu6-0007Vu-Qh; Mon, 21 Sep 2020 13:47:07 -0400
Date: Mon, 21 Sep 2020 20:47:09 +0300
Message-Id: <83d02fxbs2.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <jwvlfh32g8q.fsf-monnier+emacs@HIDDEN> (message from Stefan
 Monnier on Mon, 21 Sep 2020 13:28:59 -0400)
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009202237350453.31246@HIDDEN>
 <alpine.NEB.2.22.394.2009202327470453.3406@HIDDEN>
 <alpine.NEB.2.22.394.2009210836270453.4535@HIDDEN>
 <83tuvrxlho.fsf@HIDDEN> <jwvlfh32g8q.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: Gregory Heytings <ghe@HIDDEN>,  43519 <at> debbugs.gnu.org
> Date: Mon, 21 Sep 2020 13:28:59 -0400
> 
> Eli Zaretskii [2020-09-21 17:17:23] wrote:
> > For example: would it be okay to start the display at
> > the beginning of the screen line where we end up after
> > move_it_vertically_backward returns?
> 
> Sounds reasonable.

Thanks.  if this is agreed upon, I will try to come up with a (tested)
patch.

> Do we have something like tests (or at least a list of recipes to
> try) so we can catch regressions?

Not for the mini-window display, I'm afraid.

> It seems this part of the code is trying to satisfy needs which
> aren't clearly expressed anywhere, so while this suggestion may
> sound good to me (just like the patch I just sent), I'm afraid it
> will bring back other problems.

That's a risk, yes.  That's why I prefer "small changes", i.e. changes
that aren't supposed to affect scenarios unrelated to the ones
discussed.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 21 Sep 2020 19:18:01 +0000
Resent-Message-ID: <handler.43519.B43519.16007158425335 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.16007158425335
          (code B ref 43519); Mon, 21 Sep 2020 19:18:01 +0000
Received: (at 43519) by debbugs.gnu.org; 21 Sep 2020 19:17:22 +0000
Received: from localhost ([127.0.0.1]:56284 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kKRJR-0001Nb-Qw
	for submit <at> debbugs.gnu.org; Mon, 21 Sep 2020 15:17:22 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:45483)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1kKRJQ-0001IS-CG
 for 43519 <at> debbugs.gnu.org; Mon, 21 Sep 2020 15:17:20 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 9FE0210025B;
 Mon, 21 Sep 2020 15:17:14 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id BD28A10022A;
 Mon, 21 Sep 2020 15:17:12 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1600715832;
 bh=14i/osZK8kuU7AIl3u0TRexk9uBtjgMJsxM95usqWCU=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=NNSXOaAuy4YUh6OLmEcYWnoIp6N0n+B6yamdq6/gMMctQIICWANEH1BxfWZl5Ft3i
 zUgohUASxgBfWEilorkT3/wlLJC7cjv/M2eZQz5Wh9TouFbNtHJezT+BOBNTldwrPg
 sB3jM/lAkSToRI+0ubPRQ/+rkMzJUez4QqFO8tZZDDEgcqxRN3W3u29ilCU99yP/Uk
 f5DFaELS0KqNWHDy0kYSlVCKUhAHJq1BdZUnWEU4e+1CUJMKsLQGq3xMDXF4M+wUEF
 xkMrdqtRfsyUBBVBOip7axPGCSBj4/XTAs1S1/RD3v+FU6j2B6CYrUiPchEO6jL8N2
 MZwbf+/t0NWWQ==
Received: from alfajor (unknown [45.72.232.131])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 550BB1205B7;
 Mon, 21 Sep 2020 15:17:12 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
 <jwvd02g5bnp.fsf-monnier+emacs@HIDDEN> <83y2l3xm15.fsf@HIDDEN>
 <jwvwo0n2hgh.fsf-monnier+emacs@HIDDEN> <83eemvxbvg.fsf@HIDDEN>
-ID: <jwv4knr2d0r.fsf-monnier+emacs@HIDDEN>
Date: Mon, 21 Sep 2020 15:17:11 -0400
In-Reply-To: <83eemvxbvg.fsf@HIDDEN> (Eli Zaretskii's message of "Mon, 21 Sep
 2020 20:45:07 +0300")
Message-ID: <jwv363b2b48.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.050 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> Indeed, then we'll just rely on the "generic" behavior, which is
>> admittedly not focused on single-line (or few lines) windows, but at
>> least in the current case it works better (and simplifies the code
>> slightly).
> I believe the "works better" part is only guaranteed if
> max-mini-window-height is 1.

You're more optimistic than I am: I only said it works better "in the
current case".

> Something like that.  More generally, assume the text to be displayed
> in the mini-window is
>
>    111111111111111111
>    2222222222222222222222
>    33333333333333333333
>    444444444444444444444
>
> With point in the 4th line and max-mini-window-height = 4, there's no
> guarantee that we will see all the 4 lines, we could see just 3 and an
> empty 4th one.

You mean because of something like recentering?  IOW the kind of
situation that (in normal buffer) can (sometimes) be avoided by the
likes of `comint-scroll-show-maximum-output` and
`scroll-conservatively`?

Aah.... OK thanks, so now I did manage to reproduce a test case where
the current behavior is better than with my patch:

Set max-mini-window-height to 4, then do:

    M-: 1 ^Q ^J 2 ^Q ^J 3 ^Q ^J 4 ^Q ^J

With my patch this last C-j causes a recentering, so we can't see line
2 anymore.  Note that this recentering will still happen without my
patch if we add

    M-< M->

since our ad-hoc scrolling only occurs when the buffer's content
is changed.

And of course, we could set `scroll-conservatively` in the (mini)buffers
in which case my patch would thus recover the same behavior as the
current ad-hoc scroll (or even better since now even the `M-< M->`
avoids the recentering).

I'm not sure what would be the best way to "set `scroll-conservatively`
in the (mini)buffers", but the patch below does it "well enough" for my
tests to work.  It's probably not "good enough" for master, OTOH.

>> AFAICT our ad-hoc scrolling code gives the same result as the generic
>> scrolling code in that case.
> Not sure what ad-hoc scrolling code you allude to here.  If you mean
> what resize_mini_window does,

Yes, that's what I called "ad-hoc scroll".

> then it doesn't really scroll, it just instructs redisplay to use
> a particular buffer position as the window-start;

For me, "scrolling" is the act of changing `window-start`, so it does
seem like the right word to describe what this code does.  I called it
"ad-hoc" because it's special cased for that one particular use, as
opposed to the "generic" scroll code which is used in general.

>> I've been trying out the patch below and haven't bumped into any
>> surprising behavior yet, but admittedly, I probably lack creativity.
> IOW, you leave it entirely to the generic window-display code to
> select window-start based just on the value of point?

Yes.  It seems to work very well.
Even the corner case regression above doesn't seem very serious and can
be addressed using the scroll_conservatively code.

> And only when the mini-window cannot be enlarged enough?  I wouldn't.

We could dispense with this special case, but this is the case where
I think it's clearly at least as good a choice as whatever the generic
scrolling will do.


        Stefan


diff --git a/src/xdisp.c b/src/xdisp.c
index dfcb1d73e4..7738ac5380 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -11885,14 +11885,18 @@ resize_mini_window (struct window *w, bool exact_p)
       if (height > max_height)
 	{
 	  height = (max_height / unit) * unit;
-	  init_iterator (&it, w, ZV, ZV_BYTE, NULL, DEFAULT_FACE_ID);
-	  move_it_vertically_backward (&it, height - unit);
-	  start = it.current.pos;
+	  /* bug#43519: Let the redisplay choose the window start!
+           *
+           * init_iterator (&it, w, ZV, ZV_BYTE, NULL, DEFAULT_FACE_ID);
+	   * move_it_vertically_backward (&it, height - unit);
+	   * start = it.current.pos; */
 	}
       else
-	SET_TEXT_POS (start, BEGV, BEGV_BYTE);
+	{
+	  SET_TEXT_POS (start, BEGV, BEGV_BYTE);
 
-      SET_MARKER_FROM_TEXT_POS (w->start, start);
+          SET_MARKER_FROM_TEXT_POS (w->start, start);
+        }
 
       if (EQ (Vresize_mini_windows, Qgrow_only))
 	{
@@ -18913,6 +18917,7 @@ redisplay_window (Lisp_Object window, bool just_this_one_p)
 
   /* Try to scroll by specified few lines.  */
   if ((0 < scroll_conservatively
+       || MINI_WINDOW_P (w)
        || 0 < emacs_scroll_step
        || temp_scroll_step
        || NUMBERP (BVAR (current_buffer, scroll_up_aggressively))
@@ -18923,7 +18928,9 @@ redisplay_window (Lisp_Object window, bool just_this_one_p)
       /* The function returns -1 if new fonts were loaded, 1 if
 	 successful, 0 if not successful.  */
       int ss = try_scrolling (window, just_this_one_p,
-			      scroll_conservatively,
+			      (MINI_WINDOW_P (w)
+			       ? SCROLL_LIMIT + 1
+			       : scroll_conservatively),
 			      emacs_scroll_step,
 			      temp_scroll_step, last_line_misfit);
       switch (ss)

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 21 Sep 2020 19:48:01 +0000
Resent-Message-ID: <handler.43519.B43519.160071766518197 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.160071766518197
          (code B ref 43519); Mon, 21 Sep 2020 19:48:01 +0000
Received: (at 43519) by debbugs.gnu.org; 21 Sep 2020 19:47:45 +0000
Received: from localhost ([127.0.0.1]:56401 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kKRmr-0004jQ-82
	for submit <at> debbugs.gnu.org; Mon, 21 Sep 2020 15:47:45 -0400
Received: from eggs.gnu.org ([209.51.188.92]:45956)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1kKRmp-0004fY-LP
 for 43519 <at> debbugs.gnu.org; Mon, 21 Sep 2020 15:47:43 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:35642)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1kKRmj-0000ZQ-Sz; Mon, 21 Sep 2020 15:47:37 -0400
Received: from [176.228.60.248] (port=3927 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1kKRmj-0007WR-CQ; Mon, 21 Sep 2020 15:47:37 -0400
Date: Mon, 21 Sep 2020 22:47:40 +0300
Message-Id: <837dsmykrn.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <jwv363b2b48.fsf@HIDDEN> (message from Stefan Monnier
 on Mon, 21 Sep 2020 15:17:11 -0400)
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
 <jwvd02g5bnp.fsf-monnier+emacs@HIDDEN> <83y2l3xm15.fsf@HIDDEN>
 <jwvwo0n2hgh.fsf-monnier+emacs@HIDDEN> <83eemvxbvg.fsf@HIDDEN>
 <jwv363b2b48.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: 43519 <at> debbugs.gnu.org
> Date: Mon, 21 Sep 2020 15:17:11 -0400
> 
> >> I've been trying out the patch below and haven't bumped into any
> >> surprising behavior yet, but admittedly, I probably lack creativity.
> > IOW, you leave it entirely to the generic window-display code to
> > select window-start based just on the value of point?
> 
> Yes.  It seems to work very well.
> Even the corner case regression above doesn't seem very serious and can
> be addressed using the scroll_conservatively code.

I'd rather we didn't change the behavior all over because of this one
use case.

But if no one is interested in my proposal, you can do whatever you
wish.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 22 Sep 2020 05:27:02 +0000
Resent-Message-ID: <handler.43519.B43519.160075241722986 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: monnier@HIDDEN
Cc: 43519 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.160075241722986
          (code B ref 43519); Tue, 22 Sep 2020 05:27:02 +0000
Received: (at 43519) by debbugs.gnu.org; 22 Sep 2020 05:26:57 +0000
Received: from localhost ([127.0.0.1]:56926 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kKapN-0005yf-9m
	for submit <at> debbugs.gnu.org; Tue, 22 Sep 2020 01:26:57 -0400
Received: from eggs.gnu.org ([209.51.188.92]:36222)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1kKapL-0005yR-O9
 for 43519 <at> debbugs.gnu.org; Tue, 22 Sep 2020 01:26:56 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:43244)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1kKapG-0002Jy-2o; Tue, 22 Sep 2020 01:26:50 -0400
Received: from eliz by fencepost.gnu.org with local (Exim 4.82)
 (envelope-from <eliz@HIDDEN>)
 id 1kKapF-0007yc-Mb; Tue, 22 Sep 2020 01:26:49 -0400
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <837dsmykrn.fsf@HIDDEN> (message from Eli Zaretskii on Mon, 21
 Sep 2020 22:47:40 +0300)
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
 <jwvd02g5bnp.fsf-monnier+emacs@HIDDEN> <83y2l3xm15.fsf@HIDDEN>
 <jwvwo0n2hgh.fsf-monnier+emacs@HIDDEN> <83eemvxbvg.fsf@HIDDEN>
 <jwv363b2b48.fsf@HIDDEN> <837dsmykrn.fsf@HIDDEN>
Message-Id: <E1kKapF-0007yc-Mb@HIDDEN>
Date: Tue, 22 Sep 2020 01:26:49 -0400
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Mon, 21 Sep 2020 22:47:40 +0300
> From: Eli Zaretskii <eliz@HIDDEN>
> Cc: 43519 <at> debbugs.gnu.org
> 
> > From: Stefan Monnier <monnier@HIDDEN>
> > Cc: 43519 <at> debbugs.gnu.org
> > Date: Mon, 21 Sep 2020 15:17:11 -0400
> > 
> 
> I'd rather we didn't change the behavior all over because of this one
> use case.
> 
> But if no one is interested in my proposal, you can do whatever you
> wish.

Actually, we can do better.  I will soon install a simple change that
fixes the problems discussed in this bug and in all the related
discussions I'm aware of.  We can then take it from there, if some
issues remain.

Thanks.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Gregory Heytings <ghe@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 22 Sep 2020 06:58:01 +0000
Resent-Message-ID: <handler.43519.B43519.160075787331386 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: monnier@HIDDEN, 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.160075787331386
          (code B ref 43519); Tue, 22 Sep 2020 06:58:01 +0000
Received: (at 43519) by debbugs.gnu.org; 22 Sep 2020 06:57:53 +0000
Received: from localhost ([127.0.0.1]:56993 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kKcFN-0008AA-Gv
	for submit <at> debbugs.gnu.org; Tue, 22 Sep 2020 02:57:53 -0400
Received: from mx.sdf.org ([205.166.94.24]:58353)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ghe@HIDDEN>) id 1kKcFJ-0008A0-HD
 for 43519 <at> debbugs.gnu.org; Tue, 22 Sep 2020 02:57:51 -0400
Received: from sdf.org (IDENT:ghe@HIDDEN [205.166.94.9])
 by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 08M6vmvI022976
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO);
 Tue, 22 Sep 2020 06:57:48 GMT
Received: (from ghe@localhost)
 by sdf.org (8.15.2/8.12.8/Submit) id 08M6w3Hn007253;
 Tue, 22 Sep 2020 06:58:03 GMT
Date: Tue, 22 Sep 2020 06:57:45 +0000
From: Gregory Heytings <ghe@HIDDEN>
In-Reply-To: <83ft7bxcjj.fsf@HIDDEN>
Message-ID: <alpine.NEB.2.22.394.2009220852320453.11531@HIDDEN>
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009202237350453.31246@HIDDEN>
 <alpine.NEB.2.22.394.2009202327470453.3406@HIDDEN>
 <alpine.NEB.2.22.394.2009210836270453.4535@HIDDEN>
 <83tuvrxlho.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009211633090453.11632@HIDDEN>
 <83mu1jxhyd.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009211734460453.15638@HIDDEN>
 <83imc7xg9h.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009211811480453.18585@HIDDEN>
 <83ft7bxcjj.fsf@HIDDEN>
User-Agent: Alpine 2.22 (NEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


[I send this email again, apparently it was not delivered.  I apologize if 
you receive it twice.]

>
> My summary of the problem raised by Stefan:
>
>  . icomplete is just an example that exhibits a more general issue
>  . the more general issue is that the display after resizing the
>    mini-window is different depending on whether it uses plain buffer
>    text or an after-string overlay at EOB
>

I don't understand how you came to understand things in that way, but this 
is neither the meaning of the bug title "Overlay at end of minibuf hides 
minibuf's real content" (real content = non-overlay part), nor what was 
discussed in emacs-devel.  A short summary:

Ergus: [To implement icomplete-vertical] we need to add the exact amount 
of lines as accurate as possible.

Stefan: I *strongly* recommend you design the behavior under the 
assumption that it's OK if there are a few more lines in the (mini)buffer 
than are actually visible.

Me: if there are too many candidates the prompt disappears, leaving the 
cursor at the beginning of the minibuffer, which is counterintuitive.  A 
simple example: after (setq max-mini-window-height 1), with "M-x a" the 
"M-x" prompt and the "a" disappear.

Stefan: That can (and should) be fixed without having to reduce the number 
of candidates inserted in the (mini)buffer.

Ergus: It will be great if you give me an idea about how to do that.

Stefan: You need to figure out why the redisplay decides to hide the 
prompt rather than some other part of the (mini)buffer.

Stefan files this bug.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Gregory Heytings <ghe@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 22 Sep 2020 06:59:02 +0000
Resent-Message-ID: <handler.43519.B43519.160075788531436 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: monnier@HIDDEN, 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.160075788531436
          (code B ref 43519); Tue, 22 Sep 2020 06:59:02 +0000
Received: (at 43519) by debbugs.gnu.org; 22 Sep 2020 06:58:05 +0000
Received: from localhost ([127.0.0.1]:56997 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kKcFY-0008Ay-PU
	for submit <at> debbugs.gnu.org; Tue, 22 Sep 2020 02:58:04 -0400
Received: from mx.sdf.org ([205.166.94.24]:58341)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ghe@HIDDEN>) id 1kKcFX-0008Ao-6P
 for 43519 <at> debbugs.gnu.org; Tue, 22 Sep 2020 02:58:03 -0400
Received: from sdf.org (IDENT:ghe@HIDDEN [205.166.94.9])
 by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 08M6w2A5012689
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO);
 Tue, 22 Sep 2020 06:58:02 GMT
Received: (from ghe@localhost)
 by sdf.org (8.15.2/8.12.8/Submit) id 08M6wHnU010321;
 Tue, 22 Sep 2020 06:58:17 GMT
Date: Tue, 22 Sep 2020 06:57:59 +0000
From: Gregory Heytings <ghe@HIDDEN>
In-Reply-To: <83ft7bxcjj.fsf@HIDDEN>
Message-ID: <alpine.NEB.2.22.394.2009220853230453.11531@HIDDEN>
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009202237350453.31246@HIDDEN>
 <alpine.NEB.2.22.394.2009202327470453.3406@HIDDEN>
 <alpine.NEB.2.22.394.2009210836270453.4535@HIDDEN>
 <83tuvrxlho.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009211633090453.11632@HIDDEN>
 <83mu1jxhyd.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009211734460453.15638@HIDDEN>
 <83imc7xg9h.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009211811480453.18585@HIDDEN>
 <83ft7bxcjj.fsf@HIDDEN>
User-Agent: Alpine 2.22 (NEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


[I send this mail again, apparently it was not delivered.  I apologize if 
you receive it twice.]

>> Which is why my proposal is to not break anything, but only to give 
>> applications the control of how what they insert in the minibuffer is 
>> displayed.  A start_display_at_beginning_of_minibuffer variable that 
>> would be reset in read_minibuf() and that an application could set in 
>> minibuffer-setup-hook.  I don't understand why you would be opposed to 
>> such a change.
>
> Because it changes a long-standing behavior with inserting normal text 
> into the minibuffer.
>

I does not change anything.  Unless the user (in this case, the developer 
of completion applications such as icomplete or ido or ...) chooses to use 
that new possibility.

>
> This is not the user, this is a Lisp program that will do it.  The 
> behavior will change in that the user will be shown only the first part 
> of the text, as opposed to the last part we were showing until now.
>

The behavior will not change unless the developer (who presumably knows 
what they are doing) requests it to change.

>
> Maybe such a change in behavior is desirable (I'm not sure, and I don't 
> yet have a clear idea how will Lisp programs decide which behavior to 
> request), but it's a separate issue.
>

Okay, so shall I file another bug just to have this same discussion again?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Gregory Heytings <ghe@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 22 Sep 2020 06:59:02 +0000
Resent-Message-ID: <handler.43519.B43519.160075790531471 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: Stefan Monnier <monnier@HIDDEN>, 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.160075790531471
          (code B ref 43519); Tue, 22 Sep 2020 06:59:02 +0000
Received: (at 43519) by debbugs.gnu.org; 22 Sep 2020 06:58:25 +0000
Received: from localhost ([127.0.0.1]:57000 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kKcFt-0008BW-1Z
	for submit <at> debbugs.gnu.org; Tue, 22 Sep 2020 02:58:25 -0400
Received: from mx.sdf.org ([205.166.94.24]:58316)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ghe@HIDDEN>) id 1kKcFr-0008BP-R0
 for 43519 <at> debbugs.gnu.org; Tue, 22 Sep 2020 02:58:24 -0400
Received: from sdf.org (IDENT:ghe@HIDDEN [205.166.94.9])
 by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 08M6wNUb029638
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO);
 Tue, 22 Sep 2020 06:58:23 GMT
Received: (from ghe@localhost)
 by sdf.org (8.15.2/8.12.8/Submit) id 08M6wcM6025835;
 Tue, 22 Sep 2020 06:58:38 GMT
Date: Tue, 22 Sep 2020 06:58:20 +0000
From: Gregory Heytings <ghe@HIDDEN>
In-Reply-To: <83d02fxbs2.fsf@HIDDEN>
Message-ID: <alpine.NEB.2.22.394.2009220854210453.11531@HIDDEN>
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009202237350453.31246@HIDDEN>
 <alpine.NEB.2.22.394.2009202327470453.3406@HIDDEN>
 <alpine.NEB.2.22.394.2009210836270453.4535@HIDDEN>
 <83tuvrxlho.fsf@HIDDEN> <jwvlfh32g8q.fsf-monnier+emacs@HIDDEN>
 <83d02fxbs2.fsf@HIDDEN>
User-Agent: Alpine 2.22 (NEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


[I send this mail again, apparently it was not delivered.  I apologize if 
you receive it twice.]

>>> For example: would it be okay to start the display at the beginning of 
>>> the screen line where we end up after move_it_vertically_backward 
>>> returns?
>>
>> Sounds reasonable.
>
> Thanks.  if this is agreed upon, I will try to come up with a (tested) 
> patch.
>

I at least do not agree.  I was the one with whom Stephan was discussing 
when he filed the bug and I gave him the example with which this bug 
report started.  So I think I understand at least what I meant.  Again the 
context is completion mechanisms, in this case icomplete with a vertical 
presentation, but a similar discussion already took place about ido.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Gregory Heytings <ghe@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 22 Sep 2020 06:59:03 +0000
Resent-Message-ID: <handler.43519.B43519.160075791931499 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.160075791931499
          (code B ref 43519); Tue, 22 Sep 2020 06:59:03 +0000
Received: (at 43519) by debbugs.gnu.org; 22 Sep 2020 06:58:39 +0000
Received: from localhost ([127.0.0.1]:57003 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kKcG7-0008Bz-BE
	for submit <at> debbugs.gnu.org; Tue, 22 Sep 2020 02:58:39 -0400
Received: from mx.sdf.org ([205.166.94.24]:58305)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ghe@HIDDEN>) id 1kKcG5-0008Br-9o
 for 43519 <at> debbugs.gnu.org; Tue, 22 Sep 2020 02:58:37 -0400
Received: from sdf.org (IDENT:ghe@HIDDEN [205.166.94.9])
 by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 08M6wa2M006644
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO);
 Tue, 22 Sep 2020 06:58:36 GMT
Received: (from ghe@localhost)
 by sdf.org (8.15.2/8.12.8/Submit) id 08M6wqlN029584;
 Tue, 22 Sep 2020 06:58:52 GMT
Date: Tue, 22 Sep 2020 06:58:34 +0000
From: Gregory Heytings <ghe@HIDDEN>
In-Reply-To: <jwv363b2b48.fsf@HIDDEN>
Message-ID: <alpine.NEB.2.22.394.2009220855210453.11531@HIDDEN>
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
 <jwvd02g5bnp.fsf-monnier+emacs@HIDDEN> <83y2l3xm15.fsf@HIDDEN>
 <jwvwo0n2hgh.fsf-monnier+emacs@HIDDEN> <83eemvxbvg.fsf@HIDDEN>
 <jwv363b2b48.fsf@HIDDEN>
User-Agent: Alpine 2.22 (NEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


[I send this mail again, apparently it was not delivered.  I apologize if 
you receive it twice.]

Hi Stefan,

>> IOW, you leave it entirely to the generic window-display code to select 
>> window-start based just on the value of point?
>
> Yes.  It seems to work very well. Even the corner case regression above 
> doesn't seem very serious and can be addressed using the 
> scroll_conservatively code.
>

I tried your patch, and it works very well indeed.  It seems that it's a 
much deeper change to the code than what I suggested, which would have 
given the same effect but only upon request.  Of course I'm fine with this 
too.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Gregory Heytings <ghe@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 22 Sep 2020 06:59:03 +0000
Resent-Message-ID: <handler.43519.B43519.160075793231525 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.160075793231525
          (code B ref 43519); Tue, 22 Sep 2020 06:59:03 +0000
Received: (at 43519) by debbugs.gnu.org; 22 Sep 2020 06:58:52 +0000
Received: from localhost ([127.0.0.1]:57006 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kKcGG-0008CL-H4
	for submit <at> debbugs.gnu.org; Tue, 22 Sep 2020 02:58:52 -0400
Received: from mx.sdf.org ([205.166.94.24]:58297)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ghe@HIDDEN>) id 1kKcGE-0008CD-VD
 for 43519 <at> debbugs.gnu.org; Tue, 22 Sep 2020 02:58:47 -0400
Received: from sdf.org (IDENT:ghe@HIDDEN [205.166.94.9])
 by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 08M6wk6C009461
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO);
 Tue, 22 Sep 2020 06:58:46 GMT
Received: (from ghe@localhost)
 by sdf.org (8.15.2/8.12.8/Submit) id 08M6x15p017917;
 Tue, 22 Sep 2020 06:59:01 GMT
Date: Tue, 22 Sep 2020 06:58:43 +0000
From: Gregory Heytings <ghe@HIDDEN>
In-Reply-To: <jwv363b2b48.fsf@HIDDEN>
Message-ID: <alpine.NEB.2.22.394.2009220856150453.11531@HIDDEN>
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
 <jwvd02g5bnp.fsf-monnier+emacs@HIDDEN> <83y2l3xm15.fsf@HIDDEN>
 <jwvwo0n2hgh.fsf-monnier+emacs@HIDDEN> <83eemvxbvg.fsf@HIDDEN>
 <jwv363b2b48.fsf@HIDDEN>
User-Agent: Alpine 2.22 (NEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


[I send this mail again, apparently it was not delivered.  I apologize if 
you receive it twice.]

>> IOW, you leave it entirely to the generic window-display code to select 
>> window-start based just on the value of point?
>
> Yes.  It seems to work very well. Even the corner case regression above 
> doesn't seem very serious and can be addressed using the 
> scroll_conservatively code.
>

A last note: w->start has already been set to its default value (BEGV) 
just after entering resize_mini_window(), so the else part in your patch 
is not necessary anymore.  Your code has the same effect as simply doing:

if (height > max_height) height = (max_height / unit) * unit;

in place of the "Compute a suitable window start" part.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 22 Sep 2020 14:02:01 +0000
Resent-Message-ID: <handler.43519.B43519.160078327521045 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.160078327521045
          (code B ref 43519); Tue, 22 Sep 2020 14:02:01 +0000
Received: (at 43519) by debbugs.gnu.org; 22 Sep 2020 14:01:15 +0000
Received: from localhost ([127.0.0.1]:60944 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kKir5-0005TN-8Q
	for submit <at> debbugs.gnu.org; Tue, 22 Sep 2020 10:01:15 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:23255)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1kKir1-0005T9-S8
 for 43519 <at> debbugs.gnu.org; Tue, 22 Sep 2020 10:01:13 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 91513100257;
 Tue, 22 Sep 2020 10:01:06 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 3E91910025D;
 Tue, 22 Sep 2020 10:01:01 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1600783261;
 bh=uRJYEuqa5DIxM179iRmfrfC1HLM0SdqXD2aQK9PnSRw=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=l095TLs7KFJv/CFoZNaoskngtxjhbL3Jm7cuT1UNiAKymtUIHpukq+0+kM+BRYmoV
 KwYBfRs3pQmSu2YTY6DvdPk3n+DG7wiErkw+At6H7G5DVR+nW/oo2atGVm52srTCAG
 EAu4/wakYMzeNdj2BEZq5agjdJiuwmB6xlOVhct/Wv4H929uuOpcGOCFkLjAH4echu
 qAlgQ9h2PVfHZ3bqaQkYHeZ5jB/vy/8mCkU8yAbr7HnGUedR++VL4tUor56VEiqaHo
 c31golAFYWW/i1htwUT6HlDybreOzBTQ9dPAfJ9OxP/oMso2K4O0CvJX0e+7eHynpu
 h3pfOrLUvBebg==
Received: from alfajor (unknown [45.72.232.131])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id EC74E12037A;
 Tue, 22 Sep 2020 10:01:00 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwvo8lxzzfu.fsf-monnier+emacs@HIDDEN>
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
 <jwvd02g5bnp.fsf-monnier+emacs@HIDDEN> <83y2l3xm15.fsf@HIDDEN>
 <jwvwo0n2hgh.fsf-monnier+emacs@HIDDEN> <83eemvxbvg.fsf@HIDDEN>
 <jwv363b2b48.fsf@HIDDEN> <837dsmykrn.fsf@HIDDEN>
 <E1kKapF-0007yc-Mb@HIDDEN>
Date: Tue, 22 Sep 2020 10:00:59 -0400
In-Reply-To: <E1kKapF-0007yc-Mb@HIDDEN> (Eli Zaretskii's message of
 "Tue, 22 Sep 2020 01:26:49 -0400")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.048 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> I'd rather we didn't change the behavior all over because of this one
>> use case.

I'm not insisting on my solution, if that's what you're worried about.
I'm only working on it to better understand what's at stake.

>> But if no one is interested in my proposal, you can do whatever
>> you wish.

I don't really know how to implement it, so I was waiting for a patch
from you ;-)

> Actually, we can do better.  I will soon install a simple change that
> fixes the problems discussed in this bug and in all the related
> discussions I'm aware of.  We can then take it from there, if some
> issues remain.

Sounds great.  I'll try and see if I can write a test for this problem.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 22 Sep 2020 14:03:02 +0000
Resent-Message-ID: <handler.43519.B43519.160078336521177 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: monnier@HIDDEN
Cc: 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.160078336521177
          (code B ref 43519); Tue, 22 Sep 2020 14:03:02 +0000
Received: (at 43519) by debbugs.gnu.org; 22 Sep 2020 14:02:45 +0000
Received: from localhost ([127.0.0.1]:60948 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kKisJ-0005VB-IN
	for submit <at> debbugs.gnu.org; Tue, 22 Sep 2020 10:02:45 -0400
Received: from eggs.gnu.org ([209.51.188.92]:34840)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1kKisG-0005Ux-FR
 for 43519 <at> debbugs.gnu.org; Tue, 22 Sep 2020 10:02:30 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:50116)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1kKisB-00044o-6L; Tue, 22 Sep 2020 10:02:23 -0400
Received: from [176.228.60.248] (port=3063 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1kKis8-0005fL-MS; Tue, 22 Sep 2020 10:02:22 -0400
Date: Tue, 22 Sep 2020 17:02:25 +0300
Message-Id: <831ritykni.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <E1kKapF-0007yc-Mb@HIDDEN> (message from Eli Zaretskii
 on Tue, 22 Sep 2020 01:26:49 -0400)
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
 <jwvd02g5bnp.fsf-monnier+emacs@HIDDEN> <83y2l3xm15.fsf@HIDDEN>
 <jwvwo0n2hgh.fsf-monnier+emacs@HIDDEN> <83eemvxbvg.fsf@HIDDEN>
 <jwv363b2b48.fsf@HIDDEN> <837dsmykrn.fsf@HIDDEN>
 <E1kKapF-0007yc-Mb@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

> From: Eli Zaretskii <eliz@HIDDEN>
> Date: Tue, 22 Sep 2020 01:26:49 -0400
> Cc: 43519 <at> debbugs.gnu.org
> 
> Actually, we can do better.  I will soon install a simple change that
> fixes the problems discussed in this bug and in all the related
> discussions I'm aware of.  We can then take it from there, if some
> issues remain.

Done.

I will wait for a week or two for reports about things this change
breaks, or about issues still left to be fixed after this commit, and
if nothing surfaces, I will close the bug report.

Thanks.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 22 Sep 2020 14:12:01 +0000
Resent-Message-ID: <handler.43519.B43519.160078387722117 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Gregory Heytings <ghe@HIDDEN>
Cc: monnier@HIDDEN, 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.160078387722117
          (code B ref 43519); Tue, 22 Sep 2020 14:12:01 +0000
Received: (at 43519) by debbugs.gnu.org; 22 Sep 2020 14:11:17 +0000
Received: from localhost ([127.0.0.1]:60996 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kKj0m-0005ke-M1
	for submit <at> debbugs.gnu.org; Tue, 22 Sep 2020 10:11:16 -0400
Received: from eggs.gnu.org ([209.51.188.92]:37396)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1kKj0k-0005kS-Lj
 for 43519 <at> debbugs.gnu.org; Tue, 22 Sep 2020 10:11:15 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:50313)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1kKj0d-0005ME-QV; Tue, 22 Sep 2020 10:11:08 -0400
Received: from [176.228.60.248] (port=3595 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1kKj0a-00014Y-Rj; Tue, 22 Sep 2020 10:11:07 -0400
Date: Tue, 22 Sep 2020 17:11:10 +0300
Message-Id: <83y2l1x5oh.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <alpine.NEB.2.22.394.2009220853230453.11531@HIDDEN>
 (message from Gregory Heytings on Tue, 22 Sep 2020 06:57:59 +0000)
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009202237350453.31246@HIDDEN>
 <alpine.NEB.2.22.394.2009202327470453.3406@HIDDEN>
 <alpine.NEB.2.22.394.2009210836270453.4535@HIDDEN>
 <83tuvrxlho.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009211633090453.11632@HIDDEN>
 <83mu1jxhyd.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009211734460453.15638@HIDDEN>
 <83imc7xg9h.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009211811480453.18585@HIDDEN>
 <83ft7bxcjj.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009220853230453.11531@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Tue, 22 Sep 2020 06:57:59 +0000
> From: Gregory Heytings <ghe@HIDDEN>
> cc: monnier@HIDDEN, 43519 <at> debbugs.gnu.org
> 
> > Maybe such a change in behavior is desirable (I'm not sure, and I don't 
> > yet have a clear idea how will Lisp programs decide which behavior to 
> > request), but it's a separate issue.
> 
> Okay, so shall I file another bug just to have this same discussion again?

Yes, please.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 22 Sep 2020 14:15:02 +0000
Resent-Message-ID: <handler.43519.B43519.160078405222390 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Gregory Heytings <ghe@HIDDEN>
Cc: monnier@HIDDEN, 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.160078405222390
          (code B ref 43519); Tue, 22 Sep 2020 14:15:02 +0000
Received: (at 43519) by debbugs.gnu.org; 22 Sep 2020 14:14:12 +0000
Received: from localhost ([127.0.0.1]:32770 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kKj3c-0005p2-65
	for submit <at> debbugs.gnu.org; Tue, 22 Sep 2020 10:14:12 -0400
Received: from eggs.gnu.org ([209.51.188.92]:38274)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1kKj3a-0005or-PL
 for 43519 <at> debbugs.gnu.org; Tue, 22 Sep 2020 10:14:11 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:50413)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1kKj3V-0005ff-8p; Tue, 22 Sep 2020 10:14:05 -0400
Received: from [176.228.60.248] (port=3777 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1kKj3U-0001Tl-JW; Tue, 22 Sep 2020 10:14:05 -0400
Date: Tue, 22 Sep 2020 17:14:09 +0300
Message-Id: <83wo0lx5ji.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <alpine.NEB.2.22.394.2009220854210453.11531@HIDDEN>
 (message from Gregory Heytings on Tue, 22 Sep 2020 06:58:20 +0000)
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009202237350453.31246@HIDDEN>
 <alpine.NEB.2.22.394.2009202327470453.3406@HIDDEN>
 <alpine.NEB.2.22.394.2009210836270453.4535@HIDDEN>
 <83tuvrxlho.fsf@HIDDEN> <jwvlfh32g8q.fsf-monnier+emacs@HIDDEN>
 <83d02fxbs2.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009220854210453.11531@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Tue, 22 Sep 2020 06:58:20 +0000
> From: Gregory Heytings <ghe@HIDDEN>
> cc: Stefan Monnier <monnier@HIDDEN>, 43519 <at> debbugs.gnu.org
> 
> >>> For example: would it be okay to start the display at the beginning of 
> >>> the screen line where we end up after move_it_vertically_backward 
> >>> returns?
> >>
> >> Sounds reasonable.
> >
> > Thanks.  if this is agreed upon, I will try to come up with a (tested) 
> > patch.
> 
> I at least do not agree.

I'm sorry that all my explanations and descriptions of the code didn't
convince you.  However, since this is my area of expertise, and my
responsibility as a co-maintainer of Emacs, I must act in this case
according to my understanding of what is right and what is the most
beneficial for future Emacs development and maintenance.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Gregory Heytings <ghe@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 22 Sep 2020 15:52:02 +0000
Resent-Message-ID: <handler.43519.B43519.16007898888651 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: monnier@HIDDEN, 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.16007898888651
          (code B ref 43519); Tue, 22 Sep 2020 15:52:02 +0000
Received: (at 43519) by debbugs.gnu.org; 22 Sep 2020 15:51:28 +0000
Received: from localhost ([127.0.0.1]:33027 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kKkZk-0002FS-H4
	for submit <at> debbugs.gnu.org; Tue, 22 Sep 2020 11:51:28 -0400
Received: from mx.sdf.org ([205.166.94.24]:60046)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ghe@HIDDEN>) id 1kKkZi-0002FJ-Ct
 for 43519 <at> debbugs.gnu.org; Tue, 22 Sep 2020 11:51:27 -0400
Received: from sdf.org (IDENT:ghe@HIDDEN [205.166.94.8])
 by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 08MFpO3q013492
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO);
 Tue, 22 Sep 2020 15:51:25 GMT
Received: (from ghe@localhost)
 by sdf.org (8.15.2/8.12.8/Submit) id 08MFpeVd012975;
 Tue, 22 Sep 2020 15:51:40 GMT
Date: Tue, 22 Sep 2020 15:51:22 +0000
From: Gregory Heytings <ghe@HIDDEN>
In-Reply-To: <831ritykni.fsf@HIDDEN>
Message-ID: <alpine.NEB.2.22.394.2009221712130453.10035@HIDDEN>
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
 <jwvd02g5bnp.fsf-monnier+emacs@HIDDEN> <83y2l3xm15.fsf@HIDDEN>
 <jwvwo0n2hgh.fsf-monnier+emacs@HIDDEN> <83eemvxbvg.fsf@HIDDEN>
 <jwv363b2b48.fsf@HIDDEN> <837dsmykrn.fsf@HIDDEN>
 <E1kKapF-0007yc-Mb@HIDDEN> <831ritykni.fsf@HIDDEN>
User-Agent: Alpine 2.22 (NEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="-212064758-1738337572-1600788054=:10035"
Content-ID: <alpine.NEB.2.22.394.2009221750140453.13555@HIDDEN>
X-Spam-Score: 0.2 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.8 (/)

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---212064758-1738337572-1600788054=:10035
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-ID: <alpine.NEB.2.22.394.2009221721131453.10035@HIDDEN>


>> Actually, we can do better.  I will soon install a simple change that 
>> fixes the problems discussed in this bug and in all the related 
>> discussions I'm aware of.  We can then take it from there, if some 
>> issues remain.
>
> Done.
>
> I will wait for a week or two for reports about things this change 
> breaks, or about issues still left to be fixed after this commit, and if 
> nothing surfaces, I will close the bug report.
>

Alas...

See the two attached screenshots, taken with (setq max-mini-window-height 
1) and icomplete-mode.  "no-completion-candidates" is what a user will see 
with your change, "completion-candidates" is what a user will see without 
your change.

So your change has exactly the problem that you explained was so important 
to avoid, and that I explained was an unlikely corner case.
---212064758-1738337572-1600788054=:10035
Content-Type: image/png; name=completion-candidates.png
Content-Transfer-Encoding: BASE64
Content-ID: <alpine.NEB.2.22.394.2009221743160453.12588@HIDDEN>
Content-Description: 
Content-Disposition: attachment; filename=completion-candidates.png

iVBORw0KGgoAAAANSUhEUgAABXAAAABECAIAAACnPorlAAA8sElEQVR42u2d
d1hUx/fwZxeWRTqCgIJSlKCiglhBsWBDLNiDiiVi+do1JCaxomIhGiXGEFER
FWuwgQGlGCuoqKggCBFQQEBQlr6wsOy+f8wv973Z5rKFu4vn8/j4DHNn7p2+
c889cw6Ny+VWVFQ0NTUhAAAAAAAAAAAAAACAz8FgMHR1dTVZLFZGRgbVhQEA
AAAAAAAAAAAAQG1ITU2lc7lcqosBAAAAAAAAAAAAAIA6UVxcTKe6DAAAAAAA
AAAAAAAAqB8gUAAAAAAAAAAAAAAAoMVoUl0AAKCew4cPX758GYenT5++atUq
qksEyIi/v39qaqpAZGxsbLt27RSYBVAjKioqfH192Wz2vn37+vfvr/D7P3jw
YMuWLQih3bt3u7q6Ul1doA3ypY2xtrcm8/n8xYsX5+XlLVq0aN68eVQXBwAA
QMHIJVDw9vaurq7W1ta+ceOG8NWTJ0+eOnUKIbRx48YxY8ZQXdM2QlhY2Jkz
Z4yNja9cuUJ1WVqVmzdvBgUF4XCvXr1+++03qkv0H77Yfmk1CgsL58+fj8Pj
x4/fsGED1SVqMePHj29oaDAwMIiKipL5JvHx8Xv27MHhgwcPOjs7U10tVefI
kSNsNtvR0VGcNEEh/aKmFBQULFiwQHKaKVOmrF27VlFPnDZtWkVFxZAhQwID
A6muPQV8gdXPzs7+3//+99lkAQEBw4cPl+0RtbW1kyZNIv7U1NTU19dv3769
o6PjoEGDXF1daTQatY1Ao9EWLly4devWs2fPjhs3zszMjNryAAAAKBY48gAA
gBqQlJREhB8+fMjj8aguEQWw2ezQ0FCqS6FO5OXlJSYmIoS++eYbqssCAEBr
gL2h5+bmRkdHb9q0yc/PLysri+pCoaFDh3br1o3D4Zw8eZLqsgAAACgYOPIA
AIAa8ODBA4SQkZFRZWVlZWVlRkZG7969hZP98ssvRJh8kkUCMmShirCwMBaL
xWQyORwO1WVRD06dOsXj8ezt7fv166ekRwwdOvT27dtUVxRoy3xpY0yxa/Lb
t2/XrVu3c+fOAQMGUFgpGo3m4+MTGBgYFxfn6+vbqVMnCgsDAACgWECgoOqc
Pn06Pz9//vz51tbWwlcbGhqioqLu3bt34MABJpNJdWG/IKBfWpPKysrXr18j
hObMmXPixImGhoakpCSRAoU2TF5e3rVr1zp27NinT5+4uDiqi6MGlJSUYDnU
uHHjqC6LitKlSxfym+qGDRuePHmCEDp16lSXLl2oLh3Qphg5cuTWrVuV+oiu
XbseP36cy+XW1tbm5+enpKRER0fX1tZyOJzdu3eHh4cbGRlR2AJDhw7V0dFh
s9mXL19evXo1hSUBAABQLHDkQaWprKw8d+7c33//vWjRou3bt+fl5RGX2Gz2
uXPnfHx8jhw5kpmZ+QWe/qUQ6JdWJjk5GZ9xGDp0qIuLC/rvCYgvhODgYB6P
t2LFCi0tLarLoh7ExMTweDwNDQ0PDw+qywIAQCuhqalpZGTk5OS0ZMmSsLAw
Kysr9O+vNrUFYzKZ7u7uCKG4uLjGxkaq2wkAAEBhgIaCSmNkZHTkyJHz58/f
unXrzp07d+/exfL1mpoaHx+fmpoahJCdnd3s2bOFd8w1NTXR0dGPHz/Oz8+v
q6vT0dFp3769hYVF//79Bw8ejH9iRfLy5cv4+Pj09PTy8nIul2tiYtKhQwdH
R8cRI0Z89dVXAol9fHxKS0txeP/+/Y6OjpcvX757925xcXFTU5OdnZ23t/fo
0aM1Nf9vpOXk5Dx8+PD169dlZWWVlZVVVVUMBsPAwKBr167u7u6jRo1iMBjE
za9evXro0CHhEr569WrkyJHkmGPHjnXr1k3OuhCw2eyIiIh79+59/PhRV1e3
X79+ixYtIisoytMvgAxg8UHnzp07duw4cODA5OTk9+/f5+fni1QPaZPExcWl
p6f3799/6NChKSkpVBdHPUhISEAIOTs7GxsbK/bOZBuxBJ+1wM/j8W7fvn3r
1q03b95UVVVpamqamJhYWlq6uroOHTrUxMSEnJgw7L9z5043N7eoqKjo6Oji
4mI9Pb0+ffrMnDmzZ8+elLRqenr6mjVr0L/mltPS0s6ePfvPP/80NDTY2NhM
nz599OjR5PRFRUW+vr4CN0lKShJYw728vL7//nvhx5WUlFy7du3p06elpaWN
jY3GxsZ9+vSZNm1ajx49xJUQ/yo5OTkFBwc3NzcnJCRcv369sLCQRqN17tzZ
3d19ypQpZMWx5ubmO3fu/P3335mZmbW1tQYGBlZWVm5ubpMnT5bsVoDFYkVH
Rz99+rSoqKi2ttbIyGjQoEGzZ8+2tLSUv/qyjTGEUHJy8s2bNzMzM6uqqrS1
tS0tLQcPHjx9+nR9fX05u1IdMTMz8/f3X79+PUIoPj5+6dKlxG5EhhYjI03v
C+Ph4REXF1dXV5ecnDxixAiqmwcAAEAxUClQqKqqmjJlCg4vWLBg4cKFVLeG
KmJjY/PTTz/5+fldvHgxJiamoqICIcTlcmtqahwdHefMmSPSgnFGRsamTZuq
qqqImJqampqamvz8/MePH//+++9xcXHC3znr6up2796dnJxMjiwpKSkpKUlL
Szt//rzIXAQVFRVLly4tLCwkYrKysrKysgwNDfEeiMViLVmyRCAXl8utr68v
LS1NTk6+dOlSUFCQwMZaNmSuS1NT05o1a3Jzc/GflZWVt27devr0aWhoqLm5
uZz9AsgAh8N59uwZQmjQoEHE/wihpKSkL0SgUFdXFxoaqqmpCVqy0pObm1tW
VoYQ6tWrF9VlQQghDofz008/PX/+nIhpamp6//79+/fvHz9+HBcXFxISIi7v
vn37bt68icMsFuvOnTv37t1buXLltGnTqK1UfHx8UFAQYSE1Kytr165dZWVl
c+bMUcj9IyMjjx49yuVyiZiysrLExMTExMS5c+cuXrxYcnYul7t58+bHjx8T
MRkZGRkZGe3btyc8Tz158iQ4OLi4uJhIw2KxWCxWWlpaZGRkYGBg9+7dRd48
KioqJCSE/J3506dPMTExcXFxK1asmDp1amt2BKaxsTEwMPD+/ftETG1tbXZ2
dnZ29tWrV3fv3u3o6Cgur7K7kkKcnZ2trKzev39fVVWVk5ND7lCZW0zm3u/V
qxedTufxeA8fPgSBAgAAbQY48qDeiHxlra2t3bx5M1maIA2NjY3r168XeANv
EX/88QdZmiADubm5P//8s/zNIk9dEhMTCWkCQVVV1YkTJ6S/CYgSFMiTJ0+w
DUIsSrCwsMCnu+UZq+pFWFhYRUXF1KlT4Vi79BB+7CV8ym5NIiIiyNIE6bl/
/z4hTSDg8XiHDx/GgjaqKCkp2bdvn7C/lfDwcCzKkZPz58+HhISQpQlkzp49
+1lbfUePHiVLE0SydetWsjSBTHl5+YYNGz5+/Ch8KTIyMjg4WKTWOpfLPXTo
ECUK7cHBweR3YzLV1dUbNmwQ1y/K7krKIaSK2dnZ5HjZWkye3tfR0encuTNC
SLbVAAAAQDWBIw+qTn5+/rlz527dutXc3Eyn001NTT99+sRgMHR1dTMyMjZu
3GhnZzdnzpyRI0fS6f8nHrp3715lZSUOd+3adf369XZ2dnQ6vby8vKys7OnT
pw8ePBB+4w0PD3/z5g3x57hx42bOnNmlS5fm5uaSkpJnz57FxcVJfk9msVgM
BmPOnDmjRo0yNzevrq6+e/cu+T2cRqPZ2toOGjSoZ8+eFhYWxsbGRkZGbDb7
yZMnBw8erKurQwilpKQUFhbiX9ypU6cSkn6y/mevXr1+++03CSWRpy5sNnvU
qFGrVq3icrn79+8n9qMPHjzg8/lELhn6BZANLDhgMplOTk44ZtCgQQUFBZmZ
mRUVFQrXZlc1cnNzo6KijI2NQYerRRBvDuK+MMuDp6enp6cnDhNnEySDzUPS
aLSZM2d6enqam5traGh8+vSppKQkKSmpvLxcXMaEhAQTE5Ply5cPHDiQyWS+
efMmNDQ0PT2dz+eHhISEhYVR0rwIoT///FNfX3/lypUDBw6k0+kZGRnBwcEl
JSVcLvfvv//28fHBySwtLcl2H6dNm1ZRUTFkyJDAwEAJN8/Lyzt+/DhCSFNT
c8KECZ6enpaWlgwGo7S0NDEx8c8//2xsbAwLCxs3bpyenp7IO7BYrKioKCMj
o3nz5rm6upqamlZXVxcVFd29e1fAUC6DwRgzZsywYcMcHBz09fXZbHZ2dnZ4
eHhmZmZNTc2lS5eWL19OTv/u3TvCe2v37t19fHx69+5tYGBQW1uL1d/ITgpl
qz5q+RjLzs6+ceMGDnt5ec2YMcPKyorNZj9+/Dg0NJTFYrHZ7GPHjm3atEnm
rlRf8I4CIfThwwc5W6xFvS+Snj175ufnf/z4kcVitW/fnuq2AQAAUAAgUFBp
Kisrly1bxuFw6HS6h4fHggULEhISzpw5o6end/78+WvXrl24cCEvLy8wMLC8
vHzWrFk41/v374k7jB07ltDZ69SpU6dOnZydnYU1Revq6q5du0b8OX369FWr
VuEwg8GwtbW1tbWdMWOG5NLS6fSgoKC+ffviP01NTadPn+7s7IwlBQghY2Nj
4e/8BgYGo0aNys/Pj4iIwDGpqanEz78MyFmXdu3a+fv746Ozy5YtIwQKbDab
xWLh4xiy9QsgA1g1FCHk4uJC2NcYNGhQZGQkn89PTk6eMGEC1WVUInw+H9ti
XLp0qY6ODtXFUSewthSDwTA0NKS6LAghVFtbixBycHAgv51aWlpaWlr2799f
QkYNDY2ff/7Zzs4O/+no6Lhv376lS5cWFBTk5eW9efPG3t6ekhpxOJxDhw4R
BRs4cGBgYKCfnx9CKDMzU86bnzt3jsfj0Wi0gICAIUOGEPHW1tZ+fn6dO3fe
s2dPfX39vXv3vLy8RN6hsLDQxMQkJCTEzMwMx5iYmJiYmPTp04eczM3Nbfny
5aampkSMvr5+//79u3fvPm/evMrKSkLVheDChQvNzc0IoeHDh2/ZskVDQwPH
GxkZDRs2zN3d/dixY62vpEa8G3t7e69btw6HDQ0Nx44d6+DgsHTp0sbGxrt3
765bt05XV1cgr1K7kuD27dvinF8aGxtfuXJFeY1DSJ2I3YjMLSZ/73fo0AEH
3r9/DwIFAADaBlR+OzU0NLz9L/DxTSRGRkZz5szx8PAIDw/fsmULWeGZyWR+
/fXXFy5cWL58eY8ePby9vcmXiPDJkyfPnDlTUlIi+UHPnz9vaGjAYW1t7UWL
FslQ2uHDhxPSBIKuXbsKbOBEYmBgQITz8/PlaTQ569K3b1/CEFeXLl3IOwP8
SoBk7RdABjIyMrC6DWE6ASHk5OSkra2NvgBfD3Fxca9everRowc4Pmwpnz59
Qv9dWKgFW4398OGDBGUEkbi5uRFvehgmk0mIRNPS0qiqkaurq0DB7OzssPFa
8ndgGeDxeI8ePUII9enThyxNIPDw8MA/cxkZGRLus3z5ckKaII4tW7aQpQkE
enp62OwlYXUYw+fzcdmw6Jl4nySg0WhLly4lWxduHdLT0xFCdDp9wYIFApes
ra1HjRqFEGpqahL5/Vx5XakiEJui+vp6eVpMIb1P2HoUeZoGAABAHQENBVVn
/vz5Eq4ymcxZs2YJfAPv27fvyZMncbi+vj4sLCwsLMzMzMzZ2XnAgAHu7u4C
Cp8IIfIBgV69esn2LRT785MMm81OSEhISUnJz8+vqKhoaGgQPrdJvLfLhpx1
IZuE1NDQYDKZhHiCXFQZ+gWQAUJkMHDgQCJSU1PTxcUlOTn52bNnDQ0NWLjQ
9qitrQ0NDaXRaGvWrAGrHC0FvzlIttPemvj5+aWnp1dWVs6dO9fZ2dnBwcHG
xsba2trW1lZy54oUyPbu3RsHCgoKqKoRUQYypqamxcXFbDZbnjsXFxfjL8lp
aWn4vQ7D5/OJ/zEsFkvcTbS0tIYPHy7N4/Lz82/cuJGenv7+/Xs2my1gtUGg
LmVlZdg+kYuLi+qMLvTvSOjSpYvIU2DOzs74g3xBQUG/fv0EriqvK1UEbIUH
IUT+sZChxRTS+4SUkyzdAAAAUGvkEihIeThcUWfIx48fT7zaEaxZs0aCQd3W
yaJq9OnTZ9SoUbdu3SJHlpWVxcfHx8fH6+vrr1mzRsAdFGFzASFE9mXQIj6r
vPfixYuAgIDPWosUbv8WIWddJLixAFofssNIcjx2HtnY2PjkyRPs2bvtERYW
VllZOX78eGVYAfhCIL98Uou9vf3x48fPnj17//79x48fE2epTExMJk+e7Ovr
K+6HUqTXG2KxlVP8Kg8iz5Jgn3ziLClKCbGG8/l8yT0o4ceic+fOwg4ChTl5
8mRERISwXJsA67cTEL9fZEfClMPhcHCbi9S2IMeLHDDK60oyI0eO3Lp1KyXt
Q5x0IM4+yNZiqtn7AAAAlCOXQEFY3UueZIACwUYBL168WF1dLXCppqZm165d
TCZT3GuYzN9CJb+Ks1iszZs3k08wikPC3q6lwHddtSY/Px8bBCksLBRw206Q
lJTUJgUKOTk50dHRurq6S5cupbosakm7du3q6+tramqoLsj/p2PHjt99952/
v/+HDx/evn374sWLO3fufPz4MTw8PCcnZ8eOHTLck0KJiSqsrhKqL2wpQJjY
2NhTp06pb/Wlh2gokcVWr7rIAKHIY2FhIWUW5bUYsSsjDlcCAACoO3IJFPBq
KE6ATcQratEkLOioWpbWxM/PD5tKkgydTp8zZ86sWbNevHiRmpqalpaWnZ1N
7qnw8HDyaxj5A4XMbqIk/8TGx8eTpQkjRoyYOXNm586ddXV16XT6mTNnFGWu
XCF1aSlS9gvQIqQxkfDo0SMejyfy664Mez7V2VjHx8fzeLy6ujoJulHr16/H
gWvXrqmI6UHVoUOHDiwWS1iiSjk0Gq1jx44dO3Z0c3NbunTpr7/++tdff92/
fz81NVXkqTGRNhcIVX9xPg7UGmIwf/PNN5IPl0lAmrl84cIFHBg/fvyYMWNs
bW319PQIvYbAwEABRT9y2YqKiqhup/8Pk8nU1NTkcrnYdIgwxCiSRs6iUihk
TcbmEhBCX331FQ7I1mIK6X1iUSKsMwIAAKg7ch1GMDIyQghxuVyRp+wqKipw
oM37dVNZNDU1+/fvv3Tp0sOHD0dHR69atYr4bX779i35/B7ZTvirV6/kPHQg
knfv3hFhU1PTrVu39uzZU19fH78Kkj1TiET6XUUr1AVoHbDDSMlUVVW9evVK
5CVCZUb6t0oZsigJBerpfJlgTzFcLpd8BkrV0NTUnDdvHg6LM6cv0uwiMebl
cYhDCXjBb2pqkpDG0tIS274h3gOVQX19PXYFMnbs2A0bNvTt29fIyIh8SuLt
27fCuczMzPBb5bNnz2TQf5Gm+rKBR0JBQQGx9SLz/PlzcjI1Qv41+fnz5/j9
X19fn7w9kKHF5Ox9DPGdw8rKqlWbEgAAQGnIJVCwtrbGgbi4OIFL1dXV+Iwo
nU6HRVMVaNeu3fTp08kH0RsbG4mws7MzYamRzWbLrAUqAbJuqq6uLllAUF5e
fu/ePcnZyYYkJb8htEJdgFagoqLi9evXCKFOnTrdFsXq1atxSnGKDMThc3ES
B4VkAVQTBwcHHPisW/jWYevWrSK97WRnZ+OAuONgycnJAm+2TU1Nly5dwmGR
5vRUGSwpKCgokCAyo9Pp2KvL06dP//77b5FpKioqfv755886MJIA8Qso8rBe
fHx8Xl6ecDyNRhs8eDBCqKGh4ZdffhGwsIAJDw8XJzKQpvqygY138ng84Z+8
/Px83Iyampo9evRQ7HOVjZxrcmlp6f79+3F43LhxZIGRDC0mZ+9jsOjQ1NQU
fEYCANBmkEugQJhQDgkJCQ8PLyoq4nK5NTU1ycnJa9euxQpj/fv3F2dmv6qq
auS/EF4JAPl5+PDhypUrT5w48ezZs8LCwtraWi6XW1ZWduHCBWL7paOjQ7ZR
rK+vP2nSJOLPCxcu7N+/Py8vj8vlVldX5+TkXLt2bdmyZfJ8V7GxsSHC+fn5
p0+frqqqqqmpSUlJ+fbbbz9r7phsXvH9+/dRUVHi9t+tUBegFUhOTsZ7bpF+
4xBCQ4cOxQFxAgVHR0ccCA0NTU1NJUvQxCFDFiWxatWq22IghvfBgwdxDJx3
EIY4PoDFUpSTlJQ0f/783bt3P3z4sLKysqmpqbS09MqVK0FBQTiBra2tyIzN
zc3ff//933//XVtb29jYmJmZ+f3332PfutbW1mpnsBN/7/3w4cPhw4dLSkrE
HZmcPXs2/pgfGBi4d+/e58+f19TUNDc3V1ZWpqSk7N+/38fH58aNG/K8lhsY
GOAfwdjY2LNnz5aUlDQ1NVVUVKSnpwcGBgYFBYlzH+Pj44MtQ929e3fVqlX3
7t2rqKjAZXvw4MGaNWtOnz4tzriDlNWXAU9PTxyIiorat2/fu3fv8E9eQkKC
v78/XsqGDx+udkceZFiTm5ubq6qq0tLSjh49unjx4uLiYoSQoaHh7Nmz5W8x
eXofIVRbW4v1MaXxigUAAKAuyGVDoX///i4uLqmpqVwu9/Tp06dPnxZIwGAw
vvnmG6rr+MXR3NycmZmZmZkZEREhLs2YMWMEjp0vXrw4NTWV+CYTExMTExMj
kEseA2CjR48+efIksRsIDw8PDw8nrtLpdMlbw27duunr6xNKhsHBwcHBwcTV
Y8eOYTfvrVMXoBUgxATiBApmZmb29vZv3rwpKirKz88nFKYIHBwcunbtmpub
+/HjR39/fyJ+9OjRmzZtEnlPGbK0lOrqanEGJjHnz5+X3nIYIA47Oztzc/PS
0lIp1eal75eIiIgTJ04IJ9i4cSP5zyVLlsyZM4ccw+VyExISEhIShPOampqK
sy3q4eFx69atnTt3Cl9avny5nK1UUFCwYMEC4Xhy5JQpU9auXSvngwiwfxaE
0NWrV69evUrEe3l5ff/998Sf9vb2ixYtOn78OJ/Pj4uLE9aClB8ajebp6RkZ
Gcnj8Y4fP378+HHy1a5du9ra2iYmJgpntLGxWbZsWUhICEIoKytr27ZtCq++
DGOse/fuY8eOjY+PRwjFxsbGxsYK5NXR0VmyZInCm1F6sPRT3FWBFiBo0Zqc
m5srchZraWn99NNPAhoBsrWYPL2PEEpPT8d7D1dX19ZpdgAAgFZALg0FGo0W
EBDQt29fkVd1dHS2bdumdt9PvgT69OkjbDqeyWQePHiwf//+Snpohw4dfvzx
R5F+vKytrX18fCRnZzAY0ls9VHZdAGXD4XCePXuGENLX15eg1E3IGh48eCAy
wQ8//CBOQ0ocMmQBVBPsHPfly5eECUMK2bVrlzhXcyYmJrt37xZnvXjEiBEe
Hh4CkTQabfny5fhcgHoxfvz4rl27SpNy7ty5q1evZjAYIq8aGRlt2LBBTu99
ixYtIj6AkzE3Nw8ICJDgoGrmzJnr1q0TeVZCQ0Nj5cqV4nweSV99Gfj222/d
3NxEXtLX19+7d6/MPqGpRc412dra+uDBgyIni2wtJnPvI4TwSQodHR0QKAAA
0JaQS0MBIaSvr79///579+4lJCRkZ2dXVVVpaWlZWloOHDhw6tSpIh1oA8rG
zc0tNDT05cuXaWlpxcXFlZWV1dXVGhoa7du379at24gRI0aMGCHSKr6BgcG+
ffuePn2amJj46tUrFovV3NxsbGxsamrq4uIyYsQIyY4hP8vIkSPt7OwuXbr0
/Pnzjx8/YvsaHh4e06dPj46O/mx2b2/vLl26xMbGZmdnf/r0icPhSFBqUHZd
AKWSkpKClVkGDx4scqxihgwZgk9LJSUlzZ07VziBvb39H3/8ER4e/vz58+rq
amnUUmTIAqgmEydOPH/+PI/Hu3Xr1syZM6ktzODBgwcMGHD79u3ExMSsrKza
2lpdXV0bGxs3N7dJkyZJfl/auHGjg4NDTExMSUmJnp5e7969Z82aJfJNWPXR
0tI6dOhQZGRkUlJSUVFRfX29hCk2bdq04cOHR0dHP3v27P3793V1dXp6eg4O
Du7u7mPGjJF/DdfW1g4ODo6KikpMTMzPz+fxeObm5u7u7jNmzMA2pyXg7e09
dOhQctkMDQ0HDBjg4+MjrC0lW/VbCpPJ3LVr1/379+Pi4rKysqqqqphMZqdO
nVxdXadPn25gYKCoB7UyLV2TNTQ09PX127dv37Nnz8GDB7u6uor7EZG5xWTr
/YaGBiz7HjduHNksFAAAgLpDKy4uJoxCAQAAAECbYfv27Xfu3OnWrduxY8eo
LkvLePDgwZYtWxBCO3fuJMyFAACgviQkJOzevZtOp0dERMipXAMAAKA6/PXX
X3IdeQAAAAAAlWXBggV0Oj0nJ+fp06dUlwUAgC8XPp9/4cIFhNDYsWNBmgAA
QBsDBAoAAABA28TGxmbMmDEIIbIJWAAAgFbm3r17eXl5TCYTTJUDAND2AIEC
AAAA0GZZtmyZrq5uZmbmkydPqC4LAABfInw+H/tBmzt3rpmZGdXFAQAAUDDy
GmUEAAAAAJXF2Nj4r7/+oroUAAB8udBotLCwMKpLAQAAoCzo4nwyAQAAAAAA
AAAAAAAAiKRTp040Npv9xx9/FBcXU10YAAAAAAAAAAAAAADUAEtLy0WLFtGq
q6tFXtbX16e6hAAAAAAAAAAAAAAAKJiamhqR8Tk5OS26DxhlBAAAAAAAAAAA
AACgxYBAAQAAAAAAAAAAAACAFgNeHgAAAAAAAAAAAAAAEITH473Oyi4sKkII
dbGy6u7wFZ3+H6UEECgAAAAAAAAAAAAAACBIVvY/b3JzcfifnByEUM8e3ckJ
WnDkITg4mPZf1q1bR1XFEhMTcRkuXLigkBt2796dRqONGDFCQppr167hh4JX
czXlw4cPAmPYwsJC+uw8Hu/UqVMTJkywtrbW1dWl0+mXLl2iuk6yEBAQQKPR
jIyMqC6ILMDcB9oqpaWla9eutbe319bWJtao2tpaqsulxowePZomBDQpBpY+
QDKwVSAD8wVQESjZKhS8L/zvn+8FEoANhS8RCwsLGo02ZcoUqguiZixbtmzh
woWxsbEFBQVsNpvP5yv7ifjnnEajLVy4kOraA22BL3DuV1VVRUdHr1271s3N
rWvXrnp6ejo6OjY2NrNmzYqOjm6FWSwlnz59Gjhw4KFDh3JycjgcDtXFAYA2
Rdte+nx9fWk0mo6OzsePH6kuC9AWaNvzRRyNjY0pKSmHDx9esGBBjx496HQ6
3oG/F3p5phCqtgoNDZz//tkgkACOPACAVBQWFp44caI1n8hms3///XeEEI1G
+/7776luAABQS/z8/C5fviwQmZ+fn5+fHxkZOXLkyD///NPU1JTqYqK9e/cW
FBRQXQoAANSM/Pz8ixcvIoS++eabDh06UF0cAFBXduzYsWvXLqpL8RlUdqsg
i0Dh9evX3bt3lyGjujNlyhTV+ZwFyICFhQXRgxMnToyJiZE+b3JyMo/HQwiN
GDEiODj4q6++ateunVJLGxYW9unTJ1xUR0dHyloNgLnfdrl9+/a4ceMePXrE
YDCoLUlsbCxCSFdX9+LFi+7u7gYGBlS3TVsgMTGRCK9bt+7XX3+lukRqBix9
qs8vv/zC5XI1NDT8/f2pLsuXDswXQNmo7FYBjjwAgFQUFv7f8aEtW7Y4OTkp
W5rA5XIPHDiAwxs2bKC69gCgrhgaGo4fPz4oKOju3bv//PNPdXU1i8V68ODB
xIkTcYLU1NRjx45RXUz07t07hNCECRMmTJigOlsEAABUmfLy8rCwMITQjBkz
7OzsqC4OAKgxTCZzwIABK1euPHnyZGZmpoeHB9UlEoHKbhXgyAMASAWbzcaB
jh07tsLjLl68iFcNNze3oUOHUl17AFBX8G5bgCFDhly/fn3evHlnzpxBCEVF
Ra1YsYLactbX1yOEjI2NqS0GAABqxG+//YY3J/DhAQDkZMuWLVu2bCH+pNFo
VJdIBCq7VVCWhgKPxzt37tykSZOsrKy0tbX19fUdHBy8vLz++OOPkpISgcQP
HjzAdi/w3k4AbKXZxsZG3LP4fP7Ro0ednJx0dHTMzc2nTp16+/ZtcYlra2u3
b9/eu3dvXV1dc3Pzr7/++p9//pFQkZMnTwrbiJbGfKuNjQ1hD5bL5Z48edLV
1bV9+/ampqZubm779+/HY4LM27dvv/vuOycnJyMjI21tbWtra19f38ePH0t+
0IcPHwICAoYMGWJmZqalpWVlZbVkyZKcnBxympycHHL5S0tLEUJRUVEC9Vq8
eLHIR0RHR0+bNs3S0pLJZBobGw8YMCAgIKCiokL+6l+6dAk/GhsLEMnChQtp
NBqdTn/79u1nm1154PMOqLWWmJ9//hkHfvjhBwprLQMsFmvPnj3u7u6mpqYM
BqN9+/Y9e/acMGFCcHCw8FyDuY+BuS8SZc99wlFRUVGRou4pfYsRgx+DI0ND
QxXokuDIkSP4JhKOd/Xq1YtGo3Xt2lX4kgzDUo16/7PI0JV4Hbt///748ePN
zMz09PQGDRp09uxZcY+oq6vbvn17r169dHR0Onbs6OPjgxclaezJSw8sfW11
6WOz2YcPH0YIjRkzxsXFRabRQRmwVYD50mZ+LGRApbYKiqFaDHwhDh48iLO8
fv2aL5G6urqRI0eKe+KgQYME0t+/fx9fioiIEL7bqFGjEELW1tbkyISEBJzl
/Pnzy5YtE35KQECA8K3evXtna2srkLJ9+/YvX750cHBACA0fPlwgS3h4uPDN
r1+/zv8c1tbW+IYcDsfLy0v4JgKVPXDggJaWlsgW++mnn8Q9JSQkRFtbWzgL
g8H47bffiGRv3ryRZjD4+fkJ3L++vn7q1KkiE5uYmCQnJ8tZ/aamJvzBv1+/
fuLGkp6eHkJo7Nixn23zFjFhwgSEkLm5uZTpt23bJuX4lx98RAoh1L17dx6P
p/D747oYGhoq/M5JSUmS7dvV19eT08Pc58Pcb/W5T0CYbh4xYoT8d2tpixGD
XzI1NTUyF+nTp0/YNoSvr6/IBGlpafgpmzZtErgk27BU5d5fu3atlE0qc1dG
REScOnWKThf8VLNnzx7hpxQVFdnb2wvfPyMjQ9yiJAOw9ElGrZc+wiZIQkKC
/ENFGNgqwHxpS/OlpeBxhRAqLCxU4G1VbasgTg6Q+l+2bt8h8E8ggVI0FHbt
2iVB+KdYYmJiQkNDheMDAgL+/PNPckxTU9OkSZOExVcsFmvx4sV8pZlR+fHH
H4n3Q3EEBQV9++23jY2NIq/u2bNHpCmpAwcOrFixQth1B67s6tWrRV5qEStW
rLh69arIS+Xl5Z6enoRlAdmqr6mp6efnhxB69uzZq1evhBNcvnwZS91E/h60
JkTvaGoq/aAQoZ6wYcOG1lGIUAiVlZVTpkzBhiRbAZj7MPfl5PXr1zgwduxY
+e8mf4spHBMTE1y1qKgokUOC8NA+Z84ccrxsw5KM6ve+BGTuyry8vMWLFxPq
bATbtm0TsMvN4/G8vb2FN/Hl5eX/+9//FFURWPpkQF2WPsLQkouLy+jRo+Ws
dWsCWwUBYL6o748FJS2mDAxIyHgLZWgo9OjRAyFEo9H8/f3T09Orq6vZbPab
N2/i4uJWrlw5depUcdIXGUSPNBrNzMzs9OnT5eXl9fX1jx49IpQjOnfuzOVy
iSx//PEHjtfT0zt8+PCHDx8aGhpevnw5c+ZM9K8eu+QPAsQIkF706ODgoK2t
bWZm9uuvv+bm5jY0NBQXF9+9e3fNmjWXLl3CKV++fKmhoYEQYjAYK1asSElJ
KS8vr62tzcjI2LRpE5Ys6unpVVRUkO//6tUr4s12wIABkZGRJSUljY2NpaWl
ly5dGjhwIBIS8RKYm5sjhLy9vSVX4cmTJ8Q48fPzS09Pb2ho+Pjx4+nTpy0s
LHD83Llz5ax+QUEBrr6/v7/wffDPZMeOHZuamj7b5i2ipRoK48aNw1VmsViK
LYkAhPaapaUlh8NRxiOU9Nnh+PHjxIBxcnJKSkqqqalhs9k5OTm3b9/euHFj
jx49GhoayFlg7sPcb/25T4CdbBsaGpaWlsp5K3laDIPTLFu2TLF1JPTtL1++
LHwVn3RwdnYmR8o2LDGq3PtSaijI0JXEOmZoaGhubn727FkWi1VZWXnjxg3i
a+fPP/9MzkJ81dTS0tq7d29hYSGHw8nIyMCSHdwy8msowNJH0PaWvoiICFye
ixcvyjlOxAFbBZgvkqugRvNFBpShoaCCWwX81o/+iwwaCkoRKHTq1AkhNHDg
QCkrI89KoaGh8fTpU/IlDofj5OSEr8bFxRHxePIghK5du0ZOz+PxJk2ahC8p
fKVACHXq1KmgoEBCSryBoNFoAgXDnD59Gt/n+PHj5PgFCxbg+BkzZgjPIh6P
98MPPwisyARSrhSElbIVK1YIXMrMzMRLGJPJrKyslKf6fD4ft7+5ublARQoL
C7HuqLA6rvxIKVBobGzMzc0lzjs4ODgovCQCTJs2DT9r3759SnqEknYJZHMP
+/fvlyYLzH2Y+60/9zHnz5/H5Tx69Kj8d5OnxTAK3yVgamtrdXV1EUIzZ84U
uJSSkoIfKvCuK9uwxKhy70spUJChK4l1jMFgvHz5kpyFOFQybdo0cjxhavf0
6dMCT5k8ebI0i5I0wNJH0PaWvt69eyOE7OzsyK/EigW2ChiYL+JQo/kiA8oQ
KKjgVkFYAoAfoRJHHvBEfffuXXFxsTLuT8bT07Nfv37kGC0tre+++w6HHzx4
gAP19fXPnj1DCPXo0cPb25ucnkajbd68WXkl3L9/f+fOncVd5fF42FzWsGHD
BAqG8fHx0dHRQQg9fPiQiOTz+TiXnp5eaGiosBI+jUbbu3cvk8mUp+R4BdfQ
0Ni6davApR49esyePRshxOFwyPK2llYfgzU8S0tLb968SY6PiIjg8Xh0Ol2c
GRhlY2Njo6Wl1bVr1+3btyOEdHV1JViFUQj//PPPtWvXEEKGhobqor5FQHal
GRAQsGvXrry8POU9DuY+zH2ZefLkyaJFixBCixcvXrJkifw3VEiLKQNdXV38
ghoTE1NXV0e+hEUqNBrNx8eHiJRtWAqjyr0vGXm6ctKkSX369CHH9O7dG6uB
kPWoORwO1kTr1q3bvHnzBG6iqEUJlj4ZUJelLzY2Nj09HSH03Xff4Y+3agRs
FQSA+aKmPxZUtZgyIE46yHzkQSkChcDAQH19/bKysm7dunl5eW3btu3ixYtp
aWl8JRxAcnd3F44kZP+EadacnJzm5mbyJTL9+/fHs1HhaGtrT58+XUKCnJyc
qqoqhNC9e/c0NTU1NTU1NDQ0NDTodDqdTqfRaFpaWtgn0IcPH4hcBQUF+PjZ
qFGj2rdvr4ySI4Sys7MRQt27d8eiSgEInbGsrCyZq4/x9PTEeqECtm2wRt+4
ceMkGO9tNZycnF6+fEkILJXEvn378PnbFStW6OvrU13plkH22VtbW7t58+au
XbtaW1vPnz//7NmzhN9NRQFzH+a+bKSlpXl5edXX13t5eYWEhKhIiykP/HWL
zWZHR0cTkXw+PzIyEiHk7u5O3szJNiwFUOXe/yzydOWQIUOEIy0tLRFCNTU1
RMybN2+ampoQQsOHDxdO369fP4UsSrD0yYC6LH1BQUEIITMzs4ULFyqpKZQH
bBXIwHxR3x8LSlpMechlQEFJAgUXF5cXL14sXrxYR0fnxo0bO3bs8PHxcXJy
srKy2rFjB56xigIb/xQXWVlZKRAgzqj8pxXodDMzM2U0hYODgzijrJiPHz/i
AJ/Pb25ubm5u5vF4hGF/ckryxyXCmI1IX18Kob6+Hlt/wQdYhCHiibaVofoY
Op2OPxL+9ddf5eXlODIlJQWbTJPwoV5PT0/YWw/2oqRwXr58OXz4cKXK0T98
+IAXRyaTuWbNGuU9SEm4u7tj8SqZgoKCiIgIX1/fzp07S3CfJgMw95VRbNTW
5/6LFy88PDw+ffo0atSoy5cvYycIcj5FIS3WIlpU/XHjxpmYmCCELl68SETe
v38fO7mYO3cuObFsw1IAle39zyJnV4o0XI/HGJYgYAjfYCKfQqfTRe41W1p9
WPpailosfQihx48f37t3DyG0evVq8td+dQG2CmRgvqjpj4UMT1HxrQIZYasK
n0UpAgWEkJ2d3bFjxz5+/JibmxsVFbV+/XorK6vi4uJt27Zh6ybSI1kAIdIG
PhEpIdA6GBoaKupWIvU7KHQBQJRHQhmkr76fn5+WllZjY+O5c+dwDD4VZmlp
OXHiRKrq+O7du4aGhufPn2MXL0VFRcTxJ2UQHBzM4XAQQgsWLBD5k6b6RERE
7NmzB7+9CMBisXx9fa9cuSL93WDuY2DuK4onT554eHiUl5cPGzYsOjpapDMt
qlpMeTAYjBkzZiCEbt68ib90oX/9OxCX5KmUMKrZ+wpBclcKO4yU8m4CCPuJ
kAFY+hSOiix9e/fuRQjp6emtXLmSqqaQE9gqEMB8kfJuavdjIQPUbhUIZJAm
IOUJFDA0Gs3Ozm7y5MkHDhzIy8tbunQpQujq1au3bt0iJyO+EXG5XOGbSHYt
I9JMQ0lJCQ4YGRkJBIhLZHg8XllZmZJaQHIC4oPG9u3bJZvNuHPnjnCunJwc
ZRQbIdSuXTssNRRnCIOIl7AcSD8lzMzM8Ev7yZMnEUKNjY14v+vn5yfhfGBt
ba1wQ61atUqB7cBkMp2dnS9cuGBlZYUQun37tshRKj/V1dVHjhxBCNHpdOJ0
n9qhoaHx448/FhcXx8XF/fDDD25ubgKyZ8K8JQbmPoK531pzPykpafTo0RUV
Fe7u7jExMdLor0r5FIW0WItoafXxqQcOh4NthjU3N1+6dAkh5OnpKaANK9uw
FEAFe1/KUrVOVxobGwvcjcxnFyUpqw9LX0tRi6UvOzs7KioKIbRkyRJiIKkd
sFUggPki5eNU9jVB+qeo/lYBI9vBB+UKFMgwGAzCqMmjR4/Il/T09HCgqKhI
IBeLxZJ8koQw/SoyEjuwRAh169YNmyRJSkoSTv/06VOFn9qSkm7duuGeE1kw
cXTp0gUvFomJiSwWq6UPxXMPfwyXwFdffYUQysrKKi0tFb56+/ZtHHBwcFBI
UyxfvhwhlJqamp6ejpWa6HQ6dj9LOVpaWmPGjEEINTY2Sjg5LA9HjhzBHw+n
Tp1qb29PdY3lQktLa+zYsXv37k1KSiovLw8ODiZ+M169eoU9BmNg7iOY+60y
92/dujVu3Ljq6mp3d/fY2Fhi4CmKVm6xlkIYSsCnHhITE7EaLRY0kJFtWMpD
q638hEIKoTErklboSnt7e/yCJFIo8+TJk/r6evnrC0sfmTaz9GGfLAwGY/36
9QopA4XAVkEaYL4QqPJrgpSo7FZBpKOHFqEUgcK0adPIBo0JCKuVAmW1trbG
iwh2iEK+FBQUJPmD8M2bN1NTU8kxTU1NBw4cwGHCFou2tnb//v0RQpmZmdev
Xyen5/P5gYGBymgHadDQ0Bg/fjxCKD4+HgvbhCktLV20aBH59D6NRsNeD+vq
6pYtWyayibZt2yZuLcDW/rKysiTrVeLWa25u3rFjh8Cl169f49JqaWkRjnbk
ZPjw4XhlDw8Px4pMI0eO7NKli1LaveUQZxCk/FHx9fUln1mSLEFvbGwMDg7G
4Q0bNlBdV0Wip6e3du1aOzs7IqahoYEIw9xHMPeVP/f/+uuviRMn1tXVDRs2
7MaNGwqXJrR+i7UUwpVDYmJieXk5Lo+enh7hoZBAtmEpD6228hPHUyXvy1uh
K5lM5qBBgxBCeXl5+GsbmV27dimkvrD0kWkbS19xcfGZM2cQQrNnz/6sYXz1
ArYK4oD5QqDirwnSoOJbBbmoFoOwjsTBgweJOkvWutHQ0GAwGL6+vtevXy8r
K2toaHj37t2hQ4cIFQ5hx8uOjo74ko+PT0ZGRkNDQ25urr+/P/pXDUmcg1ka
jWZmZhYREcFisRoaGh4/fkzY4be1tSXMlvD5fKxPjhDS09MLCQkpLS3lcDhp
aWmzZs1C/2rdKNzBrDR+pFNTU/HBSxqNtmDBglu3bpWXlzc1NZWVld24cWPx
4sX4u8qbN2/IuV69ekW4gRk4cOClS5c+fPiAc129ehVbqa2vrxf5RMKh7qpV
q3JzczkcjshkhJdyhJCfn9+rV684HM6nT58iIiIIezazZ8+Ws/pkfv31V4SQ
iYkJ/npz6tSpFmVvEXipNTc3lzI9oYD32fGPETZ1JiHxsWPHcLKRI0cqr8oC
dVG4c+nr168PHjx48+bNCQkJWVlZFRUVjY2NBQUFQUFBxGcHAwOD5uZmci6Y
+zD3+cqc+xcvXsT3HDlyZF1dnaJuq8AWw+A0CnQuLcDz58/xIw4dOoRnlq+v
r8iUsg1LjKr1Phnik4aVlVViYqK4OSJDVxJfOyMiIoRviNclgXXsxIkTOIuW
ltaePXsKCwsbGxtfv36Nfziwpb2WNqMwsPQRtI2lDx+HpNFo6enpLXqKbMBW
AeaLWs8XOSHGSWFhoaLuqYJbBXFygNT/snX7DoF/AgmUJVBA4rG0tKypqRHI
gm3MCDN69GiRP8bESiHsw5kACzIJmpqaevfuLTLloEGDsBaKwMjeuXMnkoI9
e/YIN0KLpoo0XySEd2+//PKL5CziVorff/9dZHo/Pz+BlPPnz5dwf319/Xfv
3ol8hGwrRUVFBXGwWUdHR3icKBDVESg0NzcT2k03btxQXpUF6qLwXQLxUyqB
FStWCOSCuf/Zp8DclwcpVQflf5DMLYbByZQnUODz+T179kSkw5mxsbHiUso2
LPmq1/sCODk5CVdk7ty5Asla2pUyCBS4XC7+HCqMp6cnHrTyCxRg6SNoA0tf
ZWUl/m48YcIEOQeGlMBWAeaL+s4XGUhPT/9sI+/cuVPOp6jaVkFRAgWlHHmI
iooS56ekU6dO169fF9Y4Xb16tbOzs0Ckra0tIcUXh5eXF7b1SIZGo+3Zs8fb
25scqampGR0dLeyq1MTEJCwsjFqLmhs3bvz111+ZTKbIq2ZmZmFhYcJN+u23
34aEhIg0VK6pqXnw4EFxNswXLVokcl8lzJEjR4R1YjHGxsaxsbF4RVAURkZG
WC8XITR58mRlaCarIFFRUdgzbZ8+fTw9PakujhIZNmzYnj17BCJh7sPcR21i
7rdyi8kAdtWGbbV06NAB24URiWzDUmZarfdPnDiBX8kk0wpdqaGhce3atW7d
ugnEd+jQ4dChQ0QaOZ8CSx9BG1j6QkJCampqEEI//PCDAguggsBWQRiYLxjY
KqgsShEoTJgwISsr68yZM+PHjzc1NdXU1DQxMXF3d9+3b9/r16/79u0rnEVH
R+fOnTvr16/v0qWLlpaWra3tmjVrHj58KM0hsSNHjhw+fNjR0VFbWxtbAb17
9+6PP/4onNLGxiYtLW3btm2Ojo46OjodOnT4+uuvHz58SGhSUciaNWvy8vK2
bNni6upqamrKYDA6dOgwfvz4Y8eO5efnL1q0SORatnz58ry8vK1btxK5OnXq
tHDhwrS0tHXr1ol7lra29v379wMCAvr27auvry9hlWzXrl1UVNSVK1e8vb07
duzIYDAMDQ1dXFy2bNny5s0brDGlWHR1dXFAglCZEggTxNiLrAIJCgrCAXXf
JUyaNOnp06e//PLLlClT+vTpY2FhwWAw2rVrZ2trO3Xq1PPnz9++fVvYeCzM
fZj7GJWd+1LS+i3WUsgmGGfOnElow4pEtmEpM63T+y4uLikpKbNmzTI1NaV8
8FtaWr548WLbtm09e/Zs166dhYWFj49PUlKSvb09Nsoom6ltAWDpw6j70sfh
cLCkydXVlTj2r6bAVkE2YL5gYKugmtDE2XIUluIHBwdjo7KvX7/u3r071SUH
2iC1tbWdO3eurKw0NzcvKiqS//uMBCZOnBgTE2Nubi6l14bff/8du1qJjIyU
2XO7MHfv3h0xYgRCyNraOicnR/IWX1EEBARs377d0NCwsrKyFR4HAJ+lNec+
oGpA7wu0hpGRUXNz86pVq3777TeqiwMoFykHf2ho6P/+9z+E0NWrV6dMmdI6
ZYOtAqBqwI+FwsF6T8IIOBy9dv0vgQRTJk0k/ymLhkKPHj2w4XoJwi0AkIHD
hw/j36358+crY5n48OED4XYhJiamRXkJ3dTAwMBHjx4pyoEQoZ7g7+/fOtIE
AFBBlD33AVUGep/M0aNHm5ubEULYEwTQtpFm8PN4vP379yOEunfvLqClDwBf
FPBjobLACwygEtTU1Fy9enX79u0IIRqNtnjxYqpLJIibm1u7du3q6+tfvnzp
6uqKI+XUVkhPT79x4wZCyMTERL1c6QKAolD9uQ8ojy+59w8ePPjw4UMvLy8X
F5fOnTvr6em9e/fuzJkz+PS4np4evDq2baQf/JcvX8ZfC7/77jtqT/IDAFV8
yT8WagEIFACKOX78+JIlS8gx3t7e2JquSqGvr//TTz9t3bpVgffs3bs3/78e
lQHgy0Fd5j6gDKD36+rqIiMjIyMjRV7dunWrNPYjAXWkpYN/5syZsFUAvljg
x0ItaIFAYd26dXDGAVA2HTt2FOeuRn4sLCzk+VXesmWLk5PTqVOnUlNTS0tL
sd0sAAAUglLnPqDiQO+TWblypb+/P9WlAFoJGPwAID0wX1QTukLMCAOAnNBo
NAsLi2+++ebp06edOnWiujhimTx58uXLl9++fctms/l8vgKtMwLAl4m6zH1A
GXzJve/v73/lypV58+b16tXLyMiIyWR26dJl9uzZd+7cOXz4MJ2uFCdcgOrw
JQ9+AGgpMF9UGRcXFxpCSKSjB9C1A4C2CphuBgAAAABAArBVAIA2j0K8PLi4
uPw/LTmHK2J8G2UAAAAASUVORK5CYII=

---212064758-1738337572-1600788054=:10035
Content-Type: image/png; name=no-completion-candidates.png
Content-Transfer-Encoding: BASE64
Content-ID: <alpine.NEB.2.22.394.2009221743161453.12588@HIDDEN>
Content-Description: 
Content-Disposition: attachment; filename=no-completion-candidates.png

iVBORw0KGgoAAAANSUhEUgAABXAAAABECAIAAACnPorlAAA5yklEQVR42u2d
eVhTR9fAJ4EQhATZEVDZtKigIuKCS3FXtO6iiDu4fC51qa193fUVtVataC2V
KqLi1uICtKIsWmWzooCCoJRFA8gmS4AQCITk+2Pa+16zEZJAUM7v8fG5zJ1z
Z87M5CZz5swZCp/Pr6qqampqQgAAAAAAAAAAAAAAAC1Bo9F0dXU1KysrMzIy
1F0ZAAAAAAAAAAAAAAA+GlJSUqh8Pl/d1QAAAAAAAAAAAAAA4GOiqKiIqu46
AAAAAAAAAAAAAADw8QEGBQAAAAAAAAAAAAAAWo2muisAAOrn9OnTN2/exNdz
587dsGGDumsEKMjWrVtTUlJEEiMiIrp06aJCEUCcqqqqxYsXc7nco0ePuri4
qPz58fHxu3fvRggdOnTI1dVV3eoCnyCdbYx9eq8+oVC4cuXKvLw8b2/vJUuW
qLs6AAAAnQWlDAozZ86sqanR1ta+e/eu+N0LFy5cvHgRIbRjx46JEyeqW9NP
hMDAwMuXLxsYGNy6dUvddWlX7t27d+TIEXzt6Oj4448/qrtGH9Bp+6XdKCgo
WLp0Kb52d3fftm2bumvUatzd3RsaGvT09MLCwhR+SFRU1OHDh/H1iRMnnJyc
1K3WP5w5c4bL5To4OEizJqhE/Y+U/Pz8ZcuWyc4za9asTZs2qarEOXPmVFVV
jRw50tfXV93aq4FOqH5WVtb//d//tZht3759bm5uihXB4XCmT59O/Kmpqclk
Mg0NDR0cHIYNG+bq6kqhUNTbCBQKZfny5Xv27Lly5crkyZNNTU3VWx8AAIBO
Amx5AADgIyAhIYG4fvz4sUAgUHeN1ACXyw0ICFB3LSSQl5cXExODEFqxYoW6
6wIAQHuADx3Pzc0NDw/fuXOnj4/P69ev1V0pNGrUqF69evF4vAsXLqi7LgAA
AJ0F2PIAAMBHQHx8PEJIX1+fzWaz2eyMjIz+/fuLZzt+/DhxTd7JIgMFRNRF
YGBgZWUlnU7n8XjqrssHXLx4USAQ9O7de/DgwW1UxKhRo/788091Kwp8ynS2
MabaV9+bN282b9584MCBIUOGqFEpCoXi6enp6+sbGRm5ePFiCwsLNVYGAACg
kwAGhY7OpUuXWCzW0qVLraysxO82NDSEhYXFxsb+8MMPdDpd3ZXtREC/tCds
NvvVq1cIIS8vr/Pnzzc0NCQkJEg0KHzC5OXlhYaGmpubDxgwIDIyUt3V+R/F
xcXY3DN58mR116WD0rNnT/JMddu2bU+fPkUIXbx4sWfPnuquHfBJMXbs2D17
9rRpEXZ2dufOnePz+RwOh8ViJSUlhYeHczgcHo936NChoKAgfX19NbbAqFGj
dHR0uFzuzZs3v/zySzXWBAAAoJMAWx46NGw2++rVqw8ePPD29t6/f39eXh5x
i8vlXr161dPT88yZM5mZmZ1wW7IagX5pZxITE/Eeh1GjRjk7O6MPd0B0Evz8
/AQCwbp167S0tNRdlw+4c+eOQCDQ0NAYN26cuusCAEA7oampqa+vP3DgwFWr
VgUGBnbv3h39++Wo3orR6fTRo0cjhCIjIxsbG9XdTgAAAJ8+4KHQodHX1z9z
5sy1a9fu37//8OHDR48eYcN/bW2tp6dnbW0tQsjW1nbhwoXiP+Vra2vDw8Of
PHnCYrHq6up0dHQMDQ27devm4uIyfPhw/N0vkRcvXkRFRaWnp1dUVPD5fCMj
IxMTEwcHhzFjxnz22WcimT09PUtLS/H1sWPHHBwcbt68+ejRo6KioqamJltb
25kzZ06YMEFT85+RlpOT8/jx41evXpWVlbHZ7OrqahqNpqenZ2dnN3r06PHj
x9NoNOLht2/fPnXqlHgNX758OXbsWHLK2bNne/XqpaQuBFwuNzg4ODY29v37
97q6uoMHD/b29iZ7TirTL4ACYPNBjx49zM3Nhw4dmpiYWFhYyGKxJLqHfJJE
Rkamp6e7uLiMGjUqKSlJ3dX5gOjoaISQk5OTgYGBap9MDsVK0GIEfoFA8Oef
f96/fz87O7u6ulpTU9PIyMjS0tLV1XXUqFFGRkbkzERg/wMHDowYMSIsLCw8
PLyoqIjBYAwYMMDDw6Nfv35qadX09PSNGzeif6Map6WlXbly5e+//25oaLC2
tp47d+6ECRPI+d+9e7d48WKRhyQkJIi8KqdOnfrNN9+IF1dcXBwaGvrs2bPS
0tLGxkYDA4MBAwbMmTOnb9++0mqIX/4DBw708/Nrbm6Ojo7+/fffCwoKKBRK
jx49Ro8ePWvWLLJ/VnNz88OHDx88eJCZmcnhcPT09Lp37z5ixIgZM2bIPlag
srIyPDz82bNn796943A4+vr6w4YNW7hwoaWlpfLqKzbGEEKJiYn37t3LzMys
rq7W1ta2tLQcPnz43LlzmUymkl35MWJqarp169YtW7YghKKiolavXk186SvQ
YmTk6X1xxo0bFxkZWVdXl5iYOGbMGHU3DwAAwCeOOg0K1dXVs2bNwtfLli1b
vny5ulujI2Jtbb19+3YfH59ff/31zp07VVVVCCE+n19bW+vg4ODl5SUxtHJG
RsbOnTurq6uJlNra2traWhaL9eTJk59++ikyMlJ8nbOuru7QoUOJiYnkxOLi
4uLi4rS0tGvXrkmUIqiqqlq9enVBQQGR8vr169evX3ft2hX/OKusrFy1apWI
FJ/Pr6+vLy0tTUxMvHHjxpEjR0R+8SuGwro0NTVt3LgxNzcX/8lms+/fv//s
2bOAgAAzMzMl+wVQAB6Pl5ycjBAaNmwY8T9CKCEhoZMYFOrq6gICAjQ1NTug
+25ubm5ZWRlCyNHRUd11QQghHo+3ffv21NRUIqWpqamwsLCwsPDJkyeRkZH+
/v7SZI8ePXrv3j18XVlZ+fDhw9jY2PXr18+ZM0e9SkVFRR05coQIRPr69euD
Bw+WlZV5eXmp5PkhISG//PILn88nUsrKymJiYmJiYhYtWrRy5UrZ4nw+f9eu
XU+ePCFSMjIyMjIyDA0NiQOenj596ufnV1RUROSprKysrKxMS0sLCQnx9fXt
06ePxIeHhYX5+/uT15nLy8vv3LkTGRm5bt262bNnt2dHYBobG319fePi4ogU
DoeTlZWVlZV1+/btQ4cOOTg4SJNt665UI05OTt27dy8sLKyurs7JySF3qMIt
pnDvOzo6UqlUgUDw+PFjMCgAAAC0NbDl4eNG4pSVw+Hs2rWLbE2Qh8bGxi1b
tojMwFvFzz//TLYmKEBubu7333+vfLMoo0tMTAxhTSCorq4+f/68/A8BU4IK
efr0KY5BiE0J3bp1w9vOlRmrHxeBgYFVVVWzZ8/ugPvtiXPsZSxltyfBwcFk
a4L8xMXFEdYEAoFAcPr0aWzPUhfFxcVHjx4VP9YkKCgIm3KU5Nq1a/7+/mRr
ApkrV660GKvvl19+IVsTJLJnzx6yNYFMRUXFtm3b3r9/L34rJCTEz89Potc6
n88/deqUWhza/fz8yHNjMjU1Ndu2bZPWL23dlWqHsCpmZWWR0xVrMWV6X0dH
p0ePHgghxd4GAAAAQKuALQ8dHRaLdfXq1fv37zc3N1OpVGNj4/LychqNpqur
m5GRsWPHDltbWy8vr7Fjx1Kp/5iHYmNj2Ww2vrazs9uyZYutrS2VSq2oqCgr
K3v27Fl8fLz4jDcoKCg7O5v4c/LkyR4eHj179mxubi4uLk5OTo6MjJQ9T66s
rKTRaF5eXuPHjzczM6upqXn06BF5Hk6hUGxsbIYNG9avX79u3boZGBjo6+tz
udynT5+eOHGirq4OIZSUlFRQUIB/CsyePZtYgiA7pjo6Ov74448yaqKMLlwu
d/z48Rs2bODz+ceOHSN+KMfHxwuFQkJKgX4BFAMbDuh0+sCBA3HKsGHD8vPz
MzMzq6qqVO5m39HIzc0NCwszMDDomD5cxMxB2gqzMkyZMmXKlCn4mtibIBsc
HpJCoXh4eEyZMsXMzExDQ6O8vLy4uDghIaGiokKaYHR0tJGR0dq1a4cOHUqn
07OzswMCAtLT04VCob+/f2BgoFqaFyH022+/MZnM9evXDx06lEqlZmRk+Pn5
FRcX8/n8Bw8eeHp64myWlpbkuI9z5sypqqoaOXKkr6+vjIfn5eWdO3cOIaSp
qTlt2rQpU6ZYWlrSaLTS0tKYmJjffvutsbExMDBw8uTJDAZD4hMqKyvDwsL0
9fWXLFni6upqbGxcU1Pz7t27R48eicSjpdFoEydO/Pzzz+3t7ZlMJpfLzcrK
CgoKyszMrK2tvXHjxtq1a8n53759SxyS2qdPH09Pz/79++vp6XE4HOxlRj6k
UDH1UevHWFZW1t27d/H11KlT582b1717dy6X++TJk4CAgMrKSi6Xe/bs2Z07
dyrclR8v+IsbIVRSUqJki7Wq9yXSr18/Fov1/v37yspKQ0NDdbcNAADApwwY
FDo0bDZ7zZo1PB6PSqWOGzdu2bJl0dHRly9fZjAY165dCw0NvX79el5enq+v
b0VFxfz587FUYWEh8YRJkyYRzoQWFhYWFhZOTk7iLqx1dXWhoaHEn3Pnzt2w
YQO+ptFoNjY2NjY28+bNk11bKpV65MiRQYMG4T+NjY3nzp3r5OSELQUIIQMD
A/F1fj09vfHjx7NYrODgYJySkpJC/C5RACV16dKly9atW/Ge3jVr1hAGBS6X
W1lZibdjKNYvgAJgn1WEkLOzMxFfY9iwYSEhIUKhMDExcdq0aequYxsiFApx
LMbVq1fr6OiouzoSwE5JNBqta9eu6q4LQghxOByEkL29PXl2amlpaWlp6eLi
IkNQQ0Pj+++/t7W1xX86ODgcPXp09erV+fn5eXl52dnZvXv3VotGPB7v1KlT
RMWGDh3q6+vr4+ODEMrMzFTy4VevXhUIBBQKZd++fSNHjiTSraysfHx8evTo
cfjw4fr6+tjY2KlTp0p8QkFBgZGRkb+/v6mpKU4xMjIyMjIaMGAAOduIESPW
rl1rbGxMpDCZTBcXlz59+ixZsoTNZhOuLgTXr19vbm5GCLm5ue3evVtDQwOn
6+vrf/7556NHjz579mz7+4IRc+OZM2du3rwZX3ft2nXSpEn29varV69ubGx8
9OjR5s2bdXV1RWTbtCsJ/vzzT2mHXxoYGNy6davtGoewOhFf+gq3mPK9b2Ji
gi8KCwvBoAAAANCmqHPttGvXrn/+S8dcfFM7+vr6Xl5e48aNCwoK2r17N9nh
mU6nL1iw4Pr162vXru3bt+/MmTPJt4jrCxcuXL58ubi4WHZBqampDQ0N+Fpb
W9vb21uB2rq5uRHWBAI7OzuRX5YS0dPTI65ZLJYyjaakLoMGDSIihPXs2ZP8
kwXPVZCi/QIoQEZGBna3IUInIIQGDhyora2NOsFZD5GRkS9fvuzbt2+HPZGx
vLwcffj5VS84OGtJSYkMZwSJjBgxgpjpYeh0OmF5TEtLU5dGrq6uIhWztbXF
MWLJ68AKIBAI/vrrL4TQgAEDyNYEgnHjxuFvk4yMDBnPWbt2LWFNkMbu3bvJ
1gQCBoOBw14SwX0xQqEQ1w1beIn5JAGFQlm9ejU5iG/7kJ6ejhCiUqnLli0T
uWVlZTV+/HiEUFNTk8T187bryg4C8dujvr5emRZTSe8TsR4l7qYBAAAAVAh4
KHR0li5dKuMunU6fP3++yBr4oEGDLly4gK/r6+sDAwMDAwNNTU2dnJyGDBky
evRoEU9UhBB5g4Cjo6Nia6H4PD/ZcLnc6OjopKQkFotVVVXV0NAgvqGUmLcr
hpK6kENCamho0Ol0wjxBrqoC/QIoAGEyGDp0KJGoqanp7OycmJiYnJzc0NCA
jQufHhwOJyAggEKhbNy4scNG5cAzB9lx2tsTHx+f9PR0Npu9aNEiJycne3t7
a2trKysrGxsb2W0o0e7Zv39/fJGfn68ujYg6kDE2Ni4qKuJyuco8uaioCK8k
p6Wl4XkdRigUEv9jKisrpT1ES0vLzc1NnuJYLNbdu3fT09MLCwu5XK5I1AYR
XcrKynAYIGdn544zutC/I6Fnz54SN1s5OTnhBfn8/PzBgweL3G27ruwg4GA3
CCHyO1mBFlNJ7xNWTrJ1AwAAAGgLlDIoyLk5XFV7yN3d3YmpHcHGjRtlRPpt
H5GOxoABA8aPH3///n1yYllZWVRUVFRUFJPJ3Lhxo8g5VUTMBYQQ+SyDVtGi
V+Hz58/37dvXYrRI8fZvFUrqIuMYC6D9IR8YSU7Hh0c2NjY+ffoUHzn+6REY
GMhms93d3dsiPIFqIU8+1Uvv3r3PnTt35cqVuLi4J0+eEFuWjIyMZsyYsXjx
YmnfRxIPlyHeaUpaOZVB4l4SfCaftEiKckK8KoVCoewelPFO7tGjh/gBgeJc
uHAhODhY3HxMgP3bCYivCfJ5vWqHx+PhNpfobUFOlzhg2q4ryYwdO3bPnj1q
aR9ipwOx90GxFuuYvQ8AAABIQymDgrgfmjLZABWCgwL++uuvNTU1Irdqa2sP
HjxIp9OlTcMUXguVPRWvrKzctWsXeWulNGT86GwtHXZdF5AHFouFA4IUFBSI
nCdPkJCQ8EkaFHJycsLDw3V1dVevXq3uusiiS5cu9fX1tbW16q7I/zA3N//6
66+3bt1aUlLy5s2b58+fP3z48P3790FBQTk5Of/9738VeKYaLSYd4SUmQ33x
SAHiREREXLx48eNVX36IhpJY7Y9LFwUgHHm6desmp0jbtRjx44fYwwgAAAC0
EUoZFPBrWpplnUhX1ducCO3T0UTaEx8fHxzDSTZUKtXLy2v+/PnPnz9PSUlJ
S0vLysoi91RQUBB5GkZeOVH4/CrZ3/1RUVFka8KYMWM8PDx69Oihq6tLpVIv
X76sqjjqKtGltcjZL0CrkCdEwl9//SUQCCQuOyvwY7Tj/OKPiooSCAR1dXUy
fKO2bNmCL0JDQ9UVE9HExKSyslLccKl2KBSKubm5ubn5iBEjVq9effLkyT/+
+CMuLi4lJUXi5iyJMRcIV39pZxx81BBjZsWKFbL3cMlAno/M9evX8YW7u/vE
iRNtbGwYDAbh1+Dr6yviT0eu27t379TdTv+DTqdramry+XwcOkQcYhTJY2fp
UKjk1YfDJSCEPvvsM3yhWIuppPeJlxIRnREAAABoI5TajKCvr48Q4vP5Erf/
VVVV4YtP/ly3DoumpqaLi8vq1atPnz4dHh6+YcMG4kfDmzdvyBsLyQHMX758
qeSmA4m8ffuWuDY2Nt6zZ0+/fv2YTCaeCpJPppCI/D932kEXoH3AB0bKprq6
+uXLlxJvES4z8k93FRBpI1Top9Om4ANZ+Hw+eatRR0NTU3PJkiX4Wlo4fYlh
F4mhpcy5M2oBv1ebmppk5LG0tMQhZoh5YFtQX1+PjwKZNGnStm3bBg0apK+v
T94l8ebNG3EpU1NTPKtMTk5WwP9FHvUVA4+E/Px84hcOmdTUVHK2jwjlX32p
qal4/s9kMsnfwgq0mJK9jyGWE7p3796uTQkAAND5UMqgYGVlhS8iIyNFbtXU
1ODNq1QqFd7mHYEuXbrMnTuXvBG9sbGRuHZyciIiNXK5XIXdU2VAdprV1dUl
GwgqKipiY2Nli5MDScqeurSDLkA7UFVV9erVK4SQhYXFn5L48ssvcU5pjgzE
rnhpFgeViHRy7O3t8UWLx8K3D3v27JF4qE1WVha+kLbrKjExUWRm29TUdOPG
DXwtMZxeRwZbCvLz82VYpqhUKj485dmzZw8ePJCYp6qq6vvvv2/xnCAZEF80
EvfERUVF5eXliadTKJThw4cjhBoaGo4fPy4SYQETFBQkzWQgj/qKgYN3CgQC
8W8WFouFm1FTU7Nv376qLbetUfLVV1paeuzYMXw9efJkssFIgRZTsvcx2HRo
bGwMZ0YCAAC0NUoZFIjYzv7+/kFBQe/evePz+bW1tYmJiZs2bcKebC4uLtLC
7FdXV4/9F+JUAkB5Hj9+vH79+vPnzycnJxcUFHA4HD6fX1ZWdv36deJ3oY6O
Djl4MpPJnD59OvHn9evXjx07lpeXx+fza2pqcnJyQkND16xZo8yCj7W1NXHN
YrEuXbpUXV1dW1ublJT01VdftRiHmRxesbCwMCwsTNrEoB10AdqBxMREPBmQ
eKAdQmjUqFH4QppBwcHBAV8EBASkpKSQLWjSUECkjdiwYcOfUiCG94kTJ3CK
uvY7INLZLtj6o3YSEhKWLl166NChx48fs9nspqam0tLSW7duHTlyBGewsbGR
KNjc3PzNN988ePCAw+E0NjZmZmZ+8803+AhbKyurjh8XUwS83ltSUnL69Oni
4mJpOxMXLlyIF/N9fX2/++671NTU2tra5uZmNpudlJR07NgxT0/Pu3fvKjMt
19PTw981ERERV65cKS4ubmpqqqqqSk9P9/X1PXLkiLRTWjw9PXEApkePHm3Y
sCE2NraqqgrXLT4+fuPGjZcuXZIW3EFO9RVgypQp+CIsLOzo0aNv377F3yzR
0dFbt27Fbww3N7ePbsuDAq++5ubm6urqtLS0X375ZeXKlUVFRQihrl27Lly4
UPkWU6b3EUIcDge7Pcpz+BQAAACgJErFUHBxcXF2dk5JSeHz+ZcuXbp06ZJI
BhqNtmLFCnXr2Olobm7OzMzMzMwMDg6WlmfixIki285XrlyZkpJCLBbduXPn
zp07IlLKRCabMGHChQsXiJ8pQUFBQUFBxF0qlSr7N2uvXr2YTCbh/ejn5+fn
50fcPXv2LD5/vn10AdoBwkwgzaBgamrau3fv7Ozsd+/esVgswmGKwN7e3s7O
Ljc39/3791u3biXSJ0yYsHPnTonPVECktdTU1EgLMIm5du2a/CHN1I6tra2Z
mVlpaamcbvPyqx8cHHz+/HnxDDt27CD/uWrVKi8vL3IKn8+Pjo6Ojo4WlzU2
NpYWwnPcuHH3798/cOCA+K21a9cq2Ur5+fnLli0TTycnzpo1a9OmTUoWRICP
QUEI3b59+/bt20T61KlTv/nmG+LP3r17e3t7nzt3TigURkZGijsbKg+FQpky
ZUpISIhAIDh37ty5c+fId+3s7GxsbGJiYsQFra2t16xZ4+/vjxB6/fr13r17
Va6+AmOsT58+kyZNioqKQghFRERERESIyOro6KxatUrlzSg/2Mgo7a5ICxC0
6tWXm5sr8VOspaW1fft2EY8AxVpMmd5HCKWnp+OveFdX1/ZpdgAAgM6MUh4K
FApl3759gwYNknhXR0dn7969H93CTmdgwIAB4qHj6XT6iRMnXFxc2qhQExOT
//znPxIPGLOysvL09JQtTqPR5I962Na6AG0Nj8dLTk5GCDGZTBne5oStIT4+
XmKGb7/9VpqHlDQUEOnk4DNoX7x4QYQwVCMHDx6UdtSckZHRoUOHpAUJHjNm
zLhx40QSKRTK2rVr8b6Ajwt3d3c7Ozt5ci5atOjLL7+k0WgS7+rr62/btk3J
0/u8vb2JBXAyZmZm+/btk3EOlIeHx+bNmyXuldDQ0Fi/fr20o4XkV18Bvvrq
qxEjRki8xWQyv/vuO4WPXlYvSr76rKysTpw4IfHDoliLKdz7CCG8k0JHRwcM
CgAAAO2AUh4KCCEmk3ns2LHY2Njo6OisrKzq6motLS1LS8uhQ4fOnj1b4sne
QFszYsSIgICAFy9epKWlFRUVsdnsmpoaDQ0NQ0PDXr16jRkzZsyYMRKj4uvp
6R09evTZs2cxMTEvX76srKxsbm42MDAwNjZ2dnYeM2aM7IMhW2Ts2LG2trY3
btxITU19//49jq8xbty4uXPnhoeHtyg+c+bMnj17RkREZGVllZeX83g8GU4N
ba0L0KYkJSVhZ5bhw4dLHKuYkSNH4t1SCQkJixYtEs/Qu3fvn3/+OSgoKDU1
taamRh63FAVEOjlffPHFtWvXBALB/fv3PTw81FuZ4cOHDxky5M8//4yJiXn9
+jWHw9HV1bW2th4xYsT06dNlz5d27Nhhb29/586d4uJiBoPRv3//+fPnS5wJ
d3y0tLROnToVEhKSkJDw7t27+vp6GSN5zpw5bm5u4eHhycnJhYWFdXV1DAbD
3t5+9OjREydOVP5Vqa2t7efnFxYWFhMTw2KxBAKBmZnZ6NGj582bh0M7y2Dm
zJmjRo0i161r165Dhgzx9PQUd0pSTP3WQqfTDx48GBcXFxkZ+fr16+rqajqd
bmFh4erqOnfuXD09PVUV1M609tWnoaHBZDINDQ379es3fPhwV1dXae9qhVtM
sd5vaGjAJubJkyeToy8BAAAAbQSlqKiIiFYFAAAAAK1l//79Dx8+7NWr19mz
Z9Vdl9YRHx+/e/duhNCBAweIqBwAAHy8REdHHzp0iEqlBgcHK+lcAwAAALTI
H3/8odSWBwAAAABYtmwZlUrNycl59uyZuusCAEDnRSgUXr9+HSE0adIksCYA
AAC0D2BQAAAAAJTC2tp64sSJCCFypFUAAIB2JjY2Ni8vj06nQ0RwAACAdgMM
CgAAAICyrFmzRldXNzMz8+nTp+quCwAAnRGhUIiPG1u0aJGpqam6qwMAANBZ
UDYoIwAAAAAYGBj88ccf6q4FAACdFwqFEhgYqO5aAAAAdDqo0g6LAgAAAAAA
AAAAAAAAkIiFhQWFy+X+/PPPRUVF6q4MAAAAAAAAAAAAAAAfAZaWlt7e3pSa
mhqJt5lMprprCAAAAAAAAAAAAACAiqmtrZWYnpOT06rnQFBGAAAAAAAAAAAA
AABaDRgUAAAAAAAAAAAAAABoNXDKAwAAAAAAAAAAAAAAoggEglevswrevUMI
9ezevY/9Z1TqB04JYFAAAAAAAAAAAAAAAECU11l/Z+fm4uu/c3IQQv369iFn
aPMtD6GhbAolhUJJ+eOP6nZTu0+fTAolZcyYv1X+5NLSpk2bCnv3ztDWTsV6
USgpHI5AGfUnTMgmHiXPM4FOzoQJEyhicDgcdderQ9CnTx8KhTJmzBgZeUJD
Q3Gj/fHHH+quLwAAAAAAAAB0XPILCz78s1AkQ8sGhS++yBWf7or8a4upewek
vJw/dGjWqVNlOTk8Hk+o7up0ChYvXkyhUHR0dN6/f6/uugBAx6Jbt24UCmXW
rFnqrggAAAAAAADQ0VFsYtXQwPvwzwaRDBCUsRV8911pfn6jumvRiWCxWL/+
+itCaMWKFSYmJuquDgAAAAAAAAAAwMdH202s2jyGwqxZ+kKhc1uX0j5ERFQj
hHR1qb/+ajN6NENPT0Ml6sfE9CauN28uPHmyTN2KdhSOHz/O5/M1NDS2bt2q
7rp0IGJiYojrzZs3nzx5Ut01+siYNWuWUAgeRgAAAAAAAEBnoe0mVq0wKKSn
93V07KLuplAnb982IoSmTes6bVpXddfl06eioiIwMBAhNG/ePFtbW3VXBwAA
AAAAAAAA4OOjTSdWsOWhFdTXCxBCBgYtOyYAyvPjjz9yuVyE0LZt29RdFwAA
AAAAAAAAgI+SNp1YtYlB4cKFCvHAjTKOOYiP5+A8ly9XIoTi4jju7jmmpmkM
xvNhw7KuXKmUJsjhCPbvL+7f/5Wu7nMzs7QFC978/TcPqQ6iYvgfTgwIKJd9
IkNr1VeGN28av/763cCBr/T1X2hrp1pZvVy8+O2TJ3VtUVZ7wuVyT58+jRCa
OHGis/MHe0bOnDmDQ/TfuXNHmrijoyOFQrGzs5PUYm++/vrrgQMH6uvra2tr
W1lZLV68+MmTJzIqY21tTRwcwOfzL1y44OrqamhoaGxsPGLEiGPHjtXX1yOE
bty4gSv2008/SXvU8uXLKRQKlUp98+aNWho2PDx8zpw5lpaWdDrdwMBgyJAh
+/btq6qqEs8ZHx+P1bl8+TJCKC4uzt3d3dTUlMFgDBs27MqVK9KKqKur279/
v6Ojo46Ojrm5uaen599//43kO39Bfjgczv79+/v376+rq2tmZrZgwQJcijQu
XLggfjSGPKc8yNn7ZBQYYwihkpKSffv2jRw50tTUVEtLq3v37qtWrcrJySHn
ycnJIde/tLQUIRQWFiai18qVK5Xs/daq326DX+Fhyefzr169OmPGDDMzMzqd
bm5u7ubmduzYMfHjUY4dO0ahULp168bhcDw9PZlMpqOj4/3793HPTpw4UVdX
t3fv3rgC4ijW+61Cfl1ABERABERABERApBOKiCBjYqUaaqQg/Jdp03IQSkYo
OT2dK5SPoKByLEL+9/vvbGn54+JqcZ7g4IqLFyuoVFHZw4eLxaXevuXZ2KSL
5DQ0fPHiBdfePgOhZDe3LDkr3GLFZP+rrW1WRn0ymzYVSHymRH74oVRLK0Vi
lbZvfydD8P37JiLn3r1FSrZSW0DEBYiOjha5VV5eTqPREEKLFy+WKJuWloZl
d+7cKdZiP2hpaUn8IGzfvl1aZaysrBBCbm5uPB5v6tSp4rLBwcFCobCpqcnc
3BwhNHjwYInPqaurYzAYCKFJkyapqqE2bdqE61BbWys7Z319/ezZsyXqbmRk
lJiYKJI/Li6O0O7ixYtUqqjx8fDhw+KlvHv3rnfv3uLPz8jIsLe3x82ovNZv
3761sbERKcXQ0PDFixfSSgkKChJX/Pfff2+xLDl7n0CxMebv76+trS0uQqPR
fvzxRyJbdna2PG91Hx8fJXu/teq32+BXbFjeu3dPonkRIWRhYZGUlETOfPTo
UYSQmZmZh4cHkY3JZLJYLEdHRyKFSqWKCCrc+62iVbqACIiACIiACIiASGcT
EUfaxEqaHSDlQ/bs/6/IP5EMHcugsH9/EY0mYYaspZXCYvHIIo2Ngv79MyXO
pYcMefXZZy8/eYPCd9+VyK6Vn1+pNNkOblBoamrC0xhnZ2eJGaZNm4YQYjKZ
9fX14nd37NiBPzMZGRkftth3SCZ+fn4SiyPmVFu2bJEoSEwpd+3ahVPS09PF
n3Pp0iV89+bNm6pqK/kNCitWrJChu56eXn5+Pjk/MXPbv38/tuCIoKWlxWKx
yCLNzc0uLi4Snz969GhVGRQaGxv79+8vsZQhQ4Z89tlnqG0MCi32vlDRMXb8
+HHZUsQ4V9ig0NreV0D99hn8CgxLoVCoq6srQ30DA4OCggIiMzYoaGqKBhga
PHiwSMqaNWvIpSj8hmkVrdIFREAEREAEREAERDqbiAgyJlZ41k9+oGIGhVZs
eejf/5W4Jz+FktKrV4ZIzuXLjYRCZ/zv9u1WRH344YcyQ0PNK1esKysHstkD
797tZWOjhRBqbBT++usHfrmBgRXp6fUIIQaDevp0j5KS/g0Ng1686OvhYfD0
KTc7WzUbH0aNYhCKEIc1rFljTE4UCp0ZjA+aUWH15SctrX7nziKEEI1GWbfO
JCmpT0XFAA7HKSOj386d3bS1qQihXbuK2Ozmtii9rbl+/TqLxUIIffvttxIz
eHl5IYRqa2sjIiLE7+IDUZycnPr160dqsbSdO3cihGg02rp165KSkioqKjgc
TkZGxs6dO/Hi8K5du9hstrRalZSU/Pzzz6ampidPnszNzW1oaCgqKnr06NHG
jRu7dPknWOnq1as1NDQQQhcuXBB/Ap5TmZubz5gxo52b9NmzZ8SM2sfHJz09
vaGh4f3795cuXerWrRtCqKamZvv27RJlf/jhB0NDwytXrlRWVrLZ7Lt372Lv
gMbGRtzUZAWfPXuGENLS0vruu+8KCgp4PF5GRoaXl1dcXJyI977CBAYGpqen
I4QYDMbp06dLSkoaGhpevHjh4eHx9OlTaVPu5cuXE2/P27dvt7ZQeXpfsTGW
kZFBjPMhQ4aEhIQUFxc3NjaWlpbeuHFj6NCh5My9evUifw2YmZkhhGbOnCny
9XDu3DlV9b786rfz4Jd/WGLodLqPj09ERERpaWlTU1NFRUVUVNTw4cMRQlVV
VX5+fiL5+Xy+t7d3RUVFUlISPlopOTl5xowZxcXF2dnZeK2AvJFB+TeM/LRW
FxABERABERABERDpVCJkWpxYkdHT02sxjwTk91CQ9s/O7qUMo8jt21XyeyjQ
aCkvXnzgB5GWxsW35szJJacPHfoap4eGfvBYgUA4ffo/FVbeQ0EE/Ng1a1jy
i8ijPhk5PRS8vN4glEyhiKqPuXSpAj/k3LlyieId3EMBrz/b2try+XyJGTgc
DjbXeXh4iNxKSkrCA/v777//sMW8EEIUCiU0NFRSi/2zfHru3Dnxu9iqhxCy
sLCQtpBLMH36dISQmZlZU1MTOb2goAC7Z4tvxFAGOT0U1q1bh7OtW7dO5FZm
Ziae7dDpdDb7f8OJWAqm0WgvXrwgixCbSubMmUNOHzVqFE6/dOmSSCnENFJ5
DwViji3SlQKBADd+i6UQBgX5PRTk6X3FxtiyZctw+rx580TGDFbq22+/bWho
kFiiNIOCCAr0vgLqC9tl8CswLIVCoaenZ2FhofjTqqqqsLHAycmJSMQeCggh
wtNh7dq1OCU5ORmn7Nu3DyGkr69PSCnzhmkVrdIFREAEREAEREAERDqbiAgy
JlbiFgD8c6UNtzy0g0FBxGqAsbN7iVDyoEGviBQut1lDIwWh5L59M8TzP3nC
+bQNCs3Nwq5dn8tQsLFRoKOTilCyj89b1bZAixQUFGzYsMHa2ppOp/fs2dPD
wyMyMlI8W2BgIPHTXAQi1KK/v7+MghYuXIgQ0tHR4XA45HTsmE2hUMiTn+bm
5q5du8qYZzY2Nuro6CBJvuJC0pzq6tWrLbYAUX+RyeqhQ4cQQjginQobXE6D
An6VaGholJSUiN8l/OHJG6uImZv49EwoFOIV2kGDBhEpDQ0N2AVdZBUdQxh6
lDQocLlcvAzet29f8bvEinFbGBRk975iY0wgEBgbGyOEGAxGRUVFa1tDToOC
Ar3fWvUx7TD4WzssWwSbugwMDIgUbFCg0WhECrGXgbC5nD9/Hqc0NjYKlX7D
qApxXUAEREAEREAERECkM4vInlgRRgSRvQ+tNSiIbhOVQXp6X0fHLvLnV4CR
IxniiZaWtNxcXm3t/7z3c3J4zc1ChNCoURLyu7jo6uhQuVwB+kTJyeFVVzcj
hGJjOZqaqQghoVCIEBIKEfE/pqSE354Vu3Xr1rJly4iIo/n5+fn5+SEhIYMH
D/7yyy/HjRtnbGycmpp6/PjxW7duPX78WOJDjhw5ghAyNTVdvny5jLK8vLyu
XbvG5XLDw8OxcQG3Q0hICEJo9OjRPXr0ILVYTnV1NUIoNjYWb43+t8X+9/+/
LVYirURtbe25c+e22AhTpkyxsbF58+ZNUFDQF198QaQHBwcjhCZPnmxtbd2e
nYLJyspCCPXp0wdPQUUYO3Ysdol//fr1hAkTRO6OHDlSXMTS0jI3N7e2tpZI
yc7ObmpqQgi5ubmJ5x88eLCOjg4+rkYZcnJympubEUKENwQZFxcXlZQiTou9
r9gYy8/PLy8vRwiNHz/e0NBQ5dXGKNP7cqqPac/BL+ewJHj16tX58+fj4+Oz
s7NramrwWCUQF2EymeLXhB8gDjCJEMJ2NJW8YeSntbqACIiACIiACIiASKcS
IZBzYqXgTgeCtgjKSKZVHgoXL0pYoxs//m+Ekq2s/hfoKzb2n/y7d0t217e2
Tv+EPRTi4+UKFYlQ8pgxf6u2BWTj5ubWrVu306dP5+fn19fXv3r16uTJkzhI
nggzZswQ8SzA/PXXXzjDgQMHZJfV2NhoZGSEPlyeffToERYPCAj4sMXi5fw4
jBkzRrwsvEg7cOBAOdsBr8dqaWmVl/+z5YRYOZfoDo2RGHOFHOFfIvJ4KBAT
7IkTJ0rMEBMTI97sxFLwxYsXxUXGjx+PELKysiJSYmNjcf7du3dLLAVvcZe2
hCun+i2WgqesKvdQaLH3FRtjOOQEQuirr75qsSbiyOOhoFjvt1Z9grYe/K0d
lpi9e/dixxYZEJmJUx6IlF9++QUhpKGhQaQQQwirqeQbplWf/VbpAiIgAiIg
AiIgAiKdTYSgxYmVeFBGhFDbBmVsB6jyVYdCEb0AJCIkuyu0PW5ubhkZGevX
r+/Ro4e2tnafPn02btz46tWrsLCwqVOnGhkZMRiMzz///Pr162FhYRJ/Q2PX
YgaDsX79etll0Wi0efPmIYTu3buH1wYRQtevXyffUm2LYZdmefDx8dHS0mps
bLx69SpOwTuoLS0tycu2HQdCa4qkTxRVzo+l2NNEEAhU4DRE1JDSvh9++Xu/
RSS2TzurI7E+MurQAQe//MMyMDBw//792LFFMWS0TGvfsUq+kxXQBURABERA
BERABEQ6jwgZ+SdWBOL2BXnoWAYFOdHX/8dOU1zcJH5XIEBlZe3q6q9C5JlW
GBv/s1Fl/35zkfMmRP49fPhZy49THfv37xd326ZSqTNmzLhz5055eXltbe2j
R48WLFggUTwrKyssLAwhtGrVKgMDgxaLw1HQeDweXi1sbm6+ceMGQmjKlCki
1cDb1HENhTJ5+PCh9K6Rd8pnamo6e/Zs9G+4+8bGRmzp8PHxkWFilOiysWHD
BtllyVOrLl26aGlpIYSKiookZiDSlZk2E10msRSBQFBWViZDXE719fX18UVx
cbECpShMi+2s2BgjpFR1BIY4Kun9jjn45YQIsujt7f3gwYPS0lIc+ACDXyNK
ouQbRn71FdAFREAEREAEREAERDqPCEFrJ1aYNj/loR22PAQHy7Xlob6+WVMz
BaHkfv0+taCM//nPO5z/7VuetDx8vkBP7zlCyZMmZatWQfXi7e2NEKLRaC0G
k8cIBAIcKGHKlClCofDevXt4SF+7dk2sxfj44zFp0iQFKoa9vlsVTZCYNqSl
pd28eRMhRKVSiaDxKuQ///kPLujtW1kBOB0dHZH0sHzErqqoqCgikfAtDw4O
FhcR9y0ngjLa2tqK5yd8rpQMylhfX4/3qPfr10/8btsFZWyx2oqNMSIoo66u
rgJBGS0sLIjxLwMFer+16pNp08Hf2mFJbCxcsmSJxAfiiJVI5paHs2fPIilb
Ht6/fy9U+g0jJwroAiIgAiIgAiIgAiKdR4SMPBMraXaAj3vLg5xoa1NdXHQQ
QpmZDb//Xk2+JRQiX18VRL1SFxYWNHyRkMCRlkdDg+LurocQioqquX69SmKe
0tImb29WXh5P3QrJS1FR0eXLlxFCCxcuJMdTlAGFQvH09EQIxcTEVFRU4IVQ
BoMhftC9hoaGu7s7QigqKgpnk9Ripd7e3nl5eSpRx83NrW/fvgihoKAg7PI9
duzYnj17qrzd8JQSIZSQkCAj2+jRoxFCzc3N//3vf0VuvXr1CreJlpYWcSKj
AtDp9GHDhiGE8vLy8Oo0mYMHD6pEX21tbRcXF4RQZmbm77//Tr4lFAp9fX1V
UooCKDbGKBTKtGnTEEJ1dXVr1qzh8yW4Vu3du5fHk/xBxsECX79+LXs7STv0
Ppl2G/zy0NDQgC/w6ZgiXLp0KT09XflS2ucNo4AuIAIiIAIiIAIiINJ5RAgU
mFgpxcfooSAUCs+ceY9FGIxUf/+y0tImHk+QlsadPz8PoWQK5WP1UHj6tA7n
7949LSampr5ecmjGlJQ6KjUZa7ps2dv792sqKpqamgRlZU1371avXMnS1k5F
KDk7W/Lx9e/fNxGBG/fuLRJ2AL7++muEEIVCSU9Pl18qNTUVD+NTp05hZ/jF
ixdLabEUvOmaQqEsW7bs/v37FRUVTU1NZWVld+/eXblyJf6sZmdLcPpQYJFW
KBSePHkSIWRkZITX7SXGkFOep0+f4hbo3r17TExMfX29xGzEqY0IIR8fn5cv
X/J4vPLy8uDgYHNzc5y+cOFCskhrl4KFpLP0tLS0Dh8+XFBQ0NjY+OrVq0WL
FiGEunTpokAzinPmzBlcCoPB8Pf3Ly0t5fF4aWlp8+fPR/8657e/h4JQ0TH2
8uVL7HOBEBo6dOiNGzdKSkqw1O3bt/FhFtK6dfr06Vhww4YNubm5PJ5ktyYF
el8B9cm03eBv7bAUCAR4A5SGhsbBgwdzc3MbGhpKSkri4uK8vLyoVCoRzIUQ
UcBDQeHebxUK6AIiIAIiIAIiIAIinUeEQM6Jlao8FFRvUDhwoFieAwgOHy4m
RBQwKDQ1Cfr3z5T45GHDXn/22Ut1GRQUUF+EgQMl6LVo0RuRbAcPtlzQx2JQ
YLPZeK112rRprZXt168fIm3/joiIkJZTnkVyFRoUqqqq8MnzCCEdHR0ZpzAo
ycCBA8UVWbRokUi2pUuXylCcyWSKbJpQwKDA5/Ox+4A4U6ZMsbe3V6AZxWlq
aiJcvEQYNmwYPlVEpJQDBw602PUIocOHD4sX16reV2yMHT9+XLaINIPCTz/9
JDG/j4+Pkr2vmPoEbTf4FRiWW7Zskab4wIEDsbULKW1QULj3W0VrdQEREAER
EAEREAGRTiUibM3EqlNveUAIaWpSwsPtrK21RNKNjDQDA63UGDJdec6ft2Iy
NVrMtmNHt5Mnu9PpkjU1NdUMDLSys6OrWxu58Pf3x9uEvv3229bKLly4ECGE
D3owMTGZOHGi9BbbcfLkSTpdcpuYmpoGBgba2dmpSil9fX28IwMhNGPGDOLg
epVz/vx5/NaQzZkzZ8Q3g2AMDAwiIiLw1FEZNDQ0QkNDe/XqJZJuYmJy6tQp
Io+SpWhqaoaHh+PjIckYGRkFBgaq97Ov2Bj76quv/P39JfqzaWpqnjhxQuIt
hJC3t7dEc5I47dD7ZNpt8MvDgQMHRowYIZ5uZWX122+/Ee4hytMObxgFdAER
EAEREAEREAGRziOClJtYKcbHalBACFlba6Wl9d2719zBQVtHh2piorlggcHj
x/YODtrKP1yNODvrJCXZz59vYGysKXtytHGjaV6e4+7d5q6uusbGmjQaxcRE
091d7+zZniyWo7e30UdhV+HxeHi26erqijd7twpygFMPDw/Z04ONGzfm5eXt
3r3b1dXV2NiYRqOZmJi4u7ufPXuWxWJ5e3urdjpKeCItWbKk7RrQ2dk5KSlp
/vz5xsbGMurfpUuXsLCwW7duzZw509zcnEajde3a1dnZeffu3dnZ2di1Xnks
LS2fP3++d+/efv36denSpVu3bp6engkJCb17966vr0cKB4/9EGtr67S0tL17
9zo4OOjo6JiYmCxYsODx48cODg5t185yotgYW7t2bV5e3p49ewgpCwuL5cuX
p6Wlbd68WVpZ2tracXFx+/btGzRoEJPJVHvvk2mfwS9nTR4+fOjn5zd06FAG
g9GlS5c+ffps37796dOn2J9FhbT1G0YBXUAEREAEREAERECk84goObFSDIq0
0yblWfMEAOUJCAj4v//7P4TQ7du3Z82ape7qqAwOh9OjRw82m21mZvbu3Tvl
V+Y/ajgcjr6+fnNz84YNG3788Ud1VwdoW2DwAwAAAAAAtD+tmlgRB0mIIHKc
eejvf4hkmDX9C/KfH7GHAvAJIBAIjh07hhDq06fPzJkz1V0dVXL69Gk2m40Q
Wrp0KUyofvnll+bmZoQQPgkC+LSBwQ8AAAAAANDOqGtipbLtowCgADdv3sQ2
sK+//vqjjnxBpra29vbt2/v370cIUSiUlStXqrtG7ceJEyceP348depUZ2fn
Hj16MBiMt2/fXr58+fDhwwghBoPxiZmNABE68+AHAAAAAABQI+qaWIFBAVAn
Hh4eQqFQ3bVQGefOnVu1ahU5ZebMmSrfp92RqaurCwkJCQkJkXh3z549sJfq
UwUGPwAAAAAAgBpR18QKtjwAQFthbm4u7WC/Tsj69eu3bt2q7loA7QQMfgAA
AAAAgM4AVSVB1wEAIKBQKN26dVuxYsWzZ88sLCzUXZ12ZevWrbdu3VqyZImj
o6O+vj6dTu/Zs+fChQsfPnx4+vRpKhUsmJ84nXnwAwAAAAAAdDacnZ0pCCGJ
Bz2AZzIAAAAAAAAAAAAAfHqo5JQHZ2fn/wfj//RNLTHJIAAAAABJRU5ErkJg
gg==

---212064758-1738337572-1600788054=:10035--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Resent-From: Gregory Heytings <ghe@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 22 Sep 2020 15:53:01 +0000
Resent-Message-ID: <handler.43519.B43519.16007899398757 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43519
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: monnier@HIDDEN, 43519 <at> debbugs.gnu.org
Received: via spool by 43519-submit <at> debbugs.gnu.org id=B43519.16007899398757
          (code B ref 43519); Tue, 22 Sep 2020 15:53:01 +0000
Received: (at 43519) by debbugs.gnu.org; 22 Sep 2020 15:52:19 +0000
Received: from localhost ([127.0.0.1]:33035 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kKkaZ-0002HB-2R
	for submit <at> debbugs.gnu.org; Tue, 22 Sep 2020 11:52:19 -0400
Received: from mx.sdf.org ([205.166.94.24]:59926)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ghe@HIDDEN>) id 1kKkaX-0002H3-4Y
 for 43519 <at> debbugs.gnu.org; Tue, 22 Sep 2020 11:52:17 -0400
Received: from sdf.org (IDENT:ghe@HIDDEN [205.166.94.8])
 by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 08MFqGA9018424
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO);
 Tue, 22 Sep 2020 15:52:16 GMT
Received: (from ghe@localhost)
 by sdf.org (8.15.2/8.12.8/Submit) id 08MFqWbM021650;
 Tue, 22 Sep 2020 15:52:32 GMT
Date: Tue, 22 Sep 2020 15:52:14 +0000
From: Gregory Heytings <ghe@HIDDEN>
In-Reply-To: <83y2l1x5oh.fsf@HIDDEN>
Message-ID: <alpine.NEB.2.22.394.2009221722520453.10035@HIDDEN>
References: <jwvft7dveii.fsf@HIDDEN> <83wo0p1twr.fsf@HIDDEN>
 <jwvh7rta7et.fsf-monnier+emacs@HIDDEN> <83r1qx1q9v.fsf@HIDDEN>
 <jwvzh5l8med.fsf-monnier+emacs@HIDDEN> <838sd425l2.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009202237350453.31246@HIDDEN>
 <alpine.NEB.2.22.394.2009202327470453.3406@HIDDEN>
 <alpine.NEB.2.22.394.2009210836270453.4535@HIDDEN>
 <83tuvrxlho.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009211633090453.11632@HIDDEN>
 <83mu1jxhyd.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009211734460453.15638@HIDDEN>
 <83imc7xg9h.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009211811480453.18585@HIDDEN>
 <83ft7bxcjj.fsf@HIDDEN>
 <alpine.NEB.2.22.394.2009220853230453.11531@HIDDEN>
 <83y2l1x5oh.fsf@HIDDEN>
User-Agent: Alpine 2.22 (NEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


>>> Maybe such a change in behavior is desirable (I'm not sure, and I 
>>> don't yet have a clear idea how will Lisp programs decide which 
>>> behavior to request), but it's a separate issue.
>>
>> Okay, so shall I file another bug just to have this same discussion 
>> again?
>
> Yes, please.
>

But you already told me that you will be opposed to such a change...

Last modified: Tue, 22 Sep 2020 16:00:02 UTC

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