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:45:08 +0300 Message-ID: <83pn6fxk7f.fsf@gnu.org> References: <83wo0p1twr.fsf@gnu.org> <83r1qx1q9v.fsf@gnu.org> <838sd425l2.fsf@gnu.org> <83363bz0r0.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30318"; 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:48:25 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 1kKN7B-0007mP-BW for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 21 Sep 2020 16:48:25 +0200 Original-Received: from localhost ([::1]:37432 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kKN7A-0000VG-AY for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 21 Sep 2020 10:48:24 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53538) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kKN4s-0007d2-8V for bug-gnu-emacs@gnu.org; Mon, 21 Sep 2020 10:46:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44172) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kKN4r-0006Pv-Vp for bug-gnu-emacs@gnu.org; Mon, 21 Sep 2020 10:46:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kKN4r-0008CZ-Uj for bug-gnu-emacs@gnu.org; Mon, 21 Sep 2020 10:46: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:46: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.160069951828995 (code B ref 43519); Mon, 21 Sep 2020 14:46:01 +0000 Original-Received: (at 43519) by debbugs.gnu.org; 21 Sep 2020 14:45:18 +0000 Original-Received: from localhost ([127.0.0.1]:55716 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kKN49-0007Wv-QS for submit@debbugs.gnu.org; Mon, 21 Sep 2020 10:45:18 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:46414) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kKN47-0007Pj-Js for 43519@debbugs.gnu.org; Mon, 21 Sep 2020 10:45:16 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:58262) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kKN41-0006A5-Tc; Mon, 21 Sep 2020 10:45:10 -0400 Original-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 ) id 1kKN3z-0008BU-BK; Mon, 21 Sep 2020 10:45:09 -0400 In-Reply-To: (message from Gregory Heytings on Mon, 21 Sep 2020 14:18:07 +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:188596 Archived-At: > Date: Mon, 21 Sep 2020 14:18:07 +0000 > From: Gregory Heytings > cc: monnier@iro.umontreal.ca, 43519@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.