From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings via "Bug reports for GNU Emacs, the Swiss army knife of text editors" 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 15:02:31 +0000 Message-ID: References: <83wo0p1twr.fsf@gnu.org> <83r1qx1q9v.fsf@gnu.org> <838sd425l2.fsf@gnu.org> <83tuvrxlho.fsf@gnu.org> Reply-To: Gregory Heytings Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19445"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Alpine 2.22 (NEB 394 2020-01-19) Cc: monnier@iro.umontreal.ca, 43519@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Sep 21 17:03:12 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 1kKNLT-0004wO-My for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 21 Sep 2020 17:03:11 +0200 Original-Received: from localhost ([::1]:56426 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kKNLS-00019d-Po for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 21 Sep 2020 11:03:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59712) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kKNLK-00019A-Re for bug-gnu-emacs@gnu.org; Mon, 21 Sep 2020 11:03:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44213) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kKNLK-0000hI-Fo for bug-gnu-emacs@gnu.org; Mon, 21 Sep 2020 11:03:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kKNLK-0003Xy-Cv for bug-gnu-emacs@gnu.org; Mon, 21 Sep 2020 11:03:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gregory Heytings Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Sep 2020 15:03:02 +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.160070055913250 (code B ref 43519); Mon, 21 Sep 2020 15:03:02 +0000 Original-Received: (at 43519) by debbugs.gnu.org; 21 Sep 2020 15:02:39 +0000 Original-Received: from localhost ([127.0.0.1]:55759 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kKNKw-0003RL-Rs for submit@debbugs.gnu.org; Mon, 21 Sep 2020 11:02:39 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:51777) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kKNKs-0003O7-TI for 43519@debbugs.gnu.org; Mon, 21 Sep 2020 11:02:37 -0400 Original-Received: from sdf.org (IDENT:ghe@faeroes.freeshell.org [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 Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 08LF2mg3019942; Mon, 21 Sep 2020 15:02:48 GMT In-Reply-To: <83tuvrxlho.fsf@gnu.org> 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:188600 Archived-At: >> 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.