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 19:15:40 +0000 Message-ID: References: <83h7rov7xy.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="34592"; 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 21:18:07 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 1kLAHG-0008vz-UH for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 23 Sep 2020 21:18:07 +0200 Original-Received: from localhost ([::1]:35606 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kLAHF-0003RB-Qv for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 23 Sep 2020 15:18:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36176) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kLAFG-000215-Iw for bug-gnu-emacs@gnu.org; Wed, 23 Sep 2020 15:16:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54577) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kLAFG-0006Q1-A1 for bug-gnu-emacs@gnu.org; Wed, 23 Sep 2020 15:16:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kLAFG-0007XC-4G for bug-gnu-emacs@gnu.org; Wed, 23 Sep 2020 15:16: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 19:16: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.160088855128939 (code B ref 43572); Wed, 23 Sep 2020 19:16:02 +0000 Original-Received: (at 43572) by debbugs.gnu.org; 23 Sep 2020 19:15:51 +0000 Original-Received: from localhost ([127.0.0.1]:37890 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kLAF5-0007We-6p for submit@debbugs.gnu.org; Wed, 23 Sep 2020 15:15:51 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:63843) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kLAF1-0007WR-Cm for 43572@debbugs.gnu.org; Wed, 23 Sep 2020 15:15:50 -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 08NJFhhh014151 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 23 Sep 2020 19:15:43 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 08NJFw6s012184; Wed, 23 Sep 2020 19:15:58 GMT In-Reply-To: <83h7rov7xy.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:188822 Archived-At: >> In Emacs 27.1, the mini-window displays the last lines of the >> minibuffer. >> >> This is, in general, the desired behavior, but in some cases it is not. >> >> One case in which this behavior is not desirable is when completion >> candidates are displayed with an overlay at the end of the buffer. >> When this overlay is taller than max-mini-window-height, the prompt and >> the user input so far disappear. A simple example: M-: (setq >> max-mini-window-height 1), M-x icomplete-mode, M-x a. > > Actually, on the current master this example does show the "M-x a" part. > Yes, as I explain just below. It's an improvement that improves most, but not all, cases. >> This feature request follows the discussion in bug#43519. The change >> proposed there by Eli Zaretskii improves the behavior w.r.t. Emacs >> 27.1, but it is still suboptimal to display completion candidates in a >> user-friendly way. For example: >> >> Find file: | >> >> >> (where | represents the cursor) will become: >> >> | >> >> >> when the user input becomes larger than a line. That is, the "Find >> file:" prompt and the user input on the first line will disappear. > > I suggest to show a recipe for this, because the few I tried failed to > produce the described effect (with the current master). Maybe I'm > missing something. > 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: |{ ... > > 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? IOW, is what Stefan called the "real content" (prompt and user input so far) more important that the overlay (which displays completion candidates but is merely an unnecessary help for the user)? Programs such as icomplete and ido, for example, would most likely want to set this flag. (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?) > > 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. > 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. 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. 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. This happens because the default value of scroll-conservatively is 0; when it is set to 101 it does not happen anymore. This is just one case, there are possibly many other cases. But IMO, the mini-buffer is so central to Emacs, and the current behavior is so old (twenty years), that I believe changing it requires a lot of care. This could be done in small steps: 1. first with this patch (or if you want with the opposite patch: a variable start-display-at-end-of-minibuffer reset to t whenever the mini-buffer is entered), which would make it possible to everyone to try to set that variable to its non-default value to see if undesirable behaviors arise, 2. then by changing the default value to its opposite, say in Emacs 29, if it became clear enough that the new behavior does not give rise to any undesiable consequences, 3. and finally, in Emacs 3X, by removing that variable. > > 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.