From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content Date: Mon, 21 Sep 2020 17:17:23 +0300 Message-ID: <83tuvrxlho.fsf@gnu.org> References: <83wo0p1twr.fsf@gnu.org> <83r1qx1q9v.fsf@gnu.org> <838sd425l2.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3210"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, 43519@debbugs.gnu.org To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Sep 21 16:18:26 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kKMe9-0000kX-Ak for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 21 Sep 2020 16:18:25 +0200 Original-Received: from localhost ([::1]:44484 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kKMe8-0003z4-8p for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 21 Sep 2020 10:18:24 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42336) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kKMdm-0003xt-8n for bug-gnu-emacs@gnu.org; Mon, 21 Sep 2020 10:18:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44010) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kKMdl-0001nf-Us for bug-gnu-emacs@gnu.org; Mon, 21 Sep 2020 10:18:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kKMdl-0006UL-Qy for bug-gnu-emacs@gnu.org; Mon, 21 Sep 2020 10:18:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Sep 2020 14:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43519 X-GNU-PR-Package: emacs Original-Received: via spool by 43519-submit@debbugs.gnu.org id=B43519.160069785224377 (code B ref 43519); Mon, 21 Sep 2020 14:18:01 +0000 Original-Received: (at 43519) by debbugs.gnu.org; 21 Sep 2020 14:17:32 +0000 Original-Received: from localhost ([127.0.0.1]:55556 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kKMdI-0006Kt-Am for submit@debbugs.gnu.org; Mon, 21 Sep 2020 10:17:32 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:35346) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kKMdG-0006Fp-1N for 43519@debbugs.gnu.org; Mon, 21 Sep 2020 10:17:30 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:57718) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kKMd8-0001jO-9l; Mon, 21 Sep 2020 10:17:22 -0400 Original-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 ) id 1kKMd7-000419-Iu; Mon, 21 Sep 2020 10:17:22 -0400 In-Reply-To: (message from Gregory Heytings on Mon, 21 Sep 2020 06:50:22 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:188586 Archived-At: > Date: Mon, 21 Sep 2020 06:50:22 +0000 > From: Gregory Heytings > cc: Stefan Monnier , 43519@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.