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#43572: Feature request: make it possible to choose whether the first lines of the minibuffer should be displayed instead of the last ones Date: Wed, 23 Sep 2020 20:15:54 +0000 Message-ID: References: <83h7rov7xy.fsf@gnu.org> <837dskuvx3.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="22387"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Alpine 2.22 (NEB 394 2020-01-19) Cc: 43572@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Sep 23 22:19:24 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 1kLBEa-0005jL-84 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 23 Sep 2020 22:19:24 +0200 Original-Received: from localhost ([::1]:33014 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kLBEZ-0007S5-8Y for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 23 Sep 2020 16:19:23 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48414) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kLBCJ-0005mY-H0 for bug-gnu-emacs@gnu.org; Wed, 23 Sep 2020 16:17:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54672) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kLBCI-0005R4-GT for bug-gnu-emacs@gnu.org; Wed, 23 Sep 2020 16:17:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kLBCI-0001Bt-AF for bug-gnu-emacs@gnu.org; Wed, 23 Sep 2020 16:17: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: Wed, 23 Sep 2020 20:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43572 X-GNU-PR-Package: emacs Original-Received: via spool by 43572-submit@debbugs.gnu.org id=B43572.16008921634465 (code B ref 43572); Wed, 23 Sep 2020 20:17:02 +0000 Original-Received: (at 43572) by debbugs.gnu.org; 23 Sep 2020 20:16:03 +0000 Original-Received: from localhost ([127.0.0.1]:37985 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kLBBK-00019r-Ry for submit@debbugs.gnu.org; Wed, 23 Sep 2020 16:16:03 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:60584) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kLBBI-00019J-EP for 43572@debbugs.gnu.org; Wed, 23 Sep 2020 16:16:01 -0400 Original-Received: from sdf.org (IDENT:ghe@otaku.sdf.org [205.166.94.8]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 08NKFu16029114 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 23 Sep 2020 20:15:57 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 08NKGBlB002877; Wed, 23 Sep 2020 20:16:11 GMT In-Reply-To: <837dskuvx3.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:188830 Archived-At: > > And given the policy of displaying the last visible part, what would you > expect in this case? > I do not expect something else with the current policy, I suggest to add a new policy with whom the first part of the minibuffer would be displayed instead of its last part. >>> How will Lisp programs decide when to set this flag and when not to >>> set it? What would be the criteria? >> >> The criteria is simply: should the prompt and user input be displayed? > > How do you decide that? > I gave a simple and clear example of an implementation of vertical icomplete, which demonstrates how this feature would be used: (setq icomplete-separator "\n") (add-hook 'icomplete-minibuffer-setup-hook (lambda () (setq start-display-at-beginning-of-minibuffer t))) Please try it (together with my patch), you'll see what I mean. With the current behavior (with (setq icomplete-separator "\n")), whenever the prompt and user input are larger than the width of Emacs' frame and there are too many completion candidates, the prompt and user input disappear, and when there are only a few completion candidates the prompt and user input re-appear. With this patch the prompt and user input are always visible, and as many completion candidates as possible (given max-mini-window-height) are displayed after them. > > Or let me ask it differently: when will a program decide that it wants > the current behavior of perhaps NOT showing the prompt, if the > mini-window is not large enough? > In the use case of completion candidates displayed after point with an overlay at EOB, the answer is simple: never. If at some point it becomes impossible to display the prompt, say because max-mini-window-height equals 1 and the prompt and user input are larger than the width of the Emacs frame, redisplay will hide the prompt, and that's fine. As you said: "Displaying long stuff in a mini-window that is forced to be small will always present some problems, no matter what we do." >> Doing this automatically (that is, unconditionally) would have the >> consequence that when point reaches the last line of the minibuffer >> (that is, the max-mini-window-height's line), the mini-buffer would be >> recentered, and the topmost lines would be hidden. > > What resize_mini_window does ensures that recentering doesn't happen. > That is why it sets w->start: it's an indication to the display engine > to obey that window-start position if point is visible with it. > > So you are trying to solve a case that doesn't need to be solved. > I'm not trying to solve any problem here. You said: "If you are saying that any Lisp program that reads from the minibuffer will want that, then (assuming that others agree), it would be better to do this automatically in the display code." I answered this by saying: "This is not what I'm saying, and I would not dare to make such a general judgment. I only claim that it is better to make this possible. There is at least one case where I think it is better not to do this automatically." And I explained that case. >>> Binding the variable inside the minibuffer-setup-hook will affect all >>> the subsequent calls to resize_mini_window, until the next call to >>> read-from-minibuffer resets it, which may not be what the Lisp program >>> wants, and could have unintended consequences. >> >> I can't think of such unintended consequences. In the use case of >> displaying completion candidates, this (the fact that it affects all >> successive calls to resize_mini_window) is indeed what is wanted. > > Well, I _can_ think of such consequences. As I said, resize_mini_window > is called in many situations that don't involve completion, so setting > that variable to affect all of them is a bad idea. We need something > more fine-grained if we want to implement such a feature. > It would be very helpful if you could clarify what the consequences you think of are.