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#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 22:37:12 +0300 Message-ID: <837dskuvx3.fsf@gnu.org> References: <83h7rov7xy.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40174"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 43572@debbugs.gnu.org To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Sep 23 21:46:54 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 1kLAj7-000AJu-2a for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 23 Sep 2020 21:46:53 +0200 Original-Received: from localhost ([::1]:47128 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kLAj5-0004hN-NP for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 23 Sep 2020 15:46:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40222) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kLAaY-0005h2-Nl for bug-gnu-emacs@gnu.org; Wed, 23 Sep 2020 15:38:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54582) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kLAaY-0000WT-C9 for bug-gnu-emacs@gnu.org; Wed, 23 Sep 2020 15:38:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kLAaY-0008GK-8w for bug-gnu-emacs@gnu.org; Wed, 23 Sep 2020 15:38:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 Sep 2020 19:38: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.160088983731678 (code B ref 43572); Wed, 23 Sep 2020 19:38:02 +0000 Original-Received: (at 43572) by debbugs.gnu.org; 23 Sep 2020 19:37:17 +0000 Original-Received: from localhost ([127.0.0.1]:37895 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kLAZp-0008Er-4H for submit@debbugs.gnu.org; Wed, 23 Sep 2020 15:37:17 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:33218) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kLAZl-0008EZ-Ug for 43572@debbugs.gnu.org; Wed, 23 Sep 2020 15:37:15 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:49642) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kLAZe-0000Qz-Gp; Wed, 23 Sep 2020 15:37:06 -0400 Original-Received: from [176.228.60.248] (port=4653 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kLAZd-0003GV-Rn; Wed, 23 Sep 2020 15:37:06 -0400 In-Reply-To: (message from Gregory Heytings on Wed, 23 Sep 2020 19:15:40 +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:188823 Archived-At: > Date: Wed, 23 Sep 2020 19:15:40 +0000 > From: Gregory Heytings > cc: 43572@debbugs.gnu.org > > I just tested this again with current master, and actually the result is > slighly worse than what I though, when the prompt and user input becomes > larger than a line you don't see: > > | > > > but: > > | > > (IOW the characters at the beginning of the Nth line, with N > 1, > disappear.) > > Again it's difficult to give a simple recipe, because it depends on the > width of your Emacs frame and of the size of the font used in the > mini-window. The simplest recipe I can think of is: > > 1. create a "long enough" directory name, with say ten subdirectories > 2. emacs -Q > 3. make the frame width "small enough" > 4. M-: (setq max-mini-window-height 5) > 5. M-x icomplete-mode > 6. M-: (setq icomplete-separator "\n") > 7. C-x C-f and enter the "long enough" directory name > > What you will see at this point is: > > |{ > > ... > Is this worse than before the change? And given the policy of displaying the last visible part, what would you expect in this case? > > 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? 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? > (A more precise way to formulate that criteria would be: should the prompt > and user input be displayed, unless it is impossible to display them?) We are discussing the case when it's impossible to display both; the case when it's possible is easy and is already handled. > There is at least one case where I think it is better not to do this > automatically. As Stefan indicated in bug#43519, with M-:, when you input > data, the current behavior is to always have point on the last line of the > minibuffer. That case doesn't need any special handling in resize_mini_window, because the display engine will always make sure point is visible. If the window-start point determined by resize_mini_window doesn't allow point to be visible, the display engine will find another window-start, which would. > 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. > > 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.