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 18:17:29 +0300 Message-ID: <83h7rov7xy.fsf@gnu.org> References: Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5816"; 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 17:23:43 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 1kL6cR-0001Pt-Az for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 23 Sep 2020 17:23:43 +0200 Original-Received: from localhost ([::1]:53766 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kL6cQ-0000L3-8F for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 23 Sep 2020 11:23:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35070) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kL6Ww-00026A-Nd for bug-gnu-emacs@gnu.org; Wed, 23 Sep 2020 11:18:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54208) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kL6Ww-0004o0-C0 for bug-gnu-emacs@gnu.org; Wed, 23 Sep 2020 11:18:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kL6Ww-0007hB-88 for bug-gnu-emacs@gnu.org; Wed, 23 Sep 2020 11:18: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 15:18: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.160087425329503 (code B ref 43572); Wed, 23 Sep 2020 15:18:02 +0000 Original-Received: (at 43572) by debbugs.gnu.org; 23 Sep 2020 15:17:33 +0000 Original-Received: from localhost ([127.0.0.1]:37514 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kL6WT-0007fm-2h for submit@debbugs.gnu.org; Wed, 23 Sep 2020 11:17:33 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:56392) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kL6WS-0007fa-7B for 43572@debbugs.gnu.org; Wed, 23 Sep 2020 11:17:32 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:46163) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kL6WM-0004jY-Vw; Wed, 23 Sep 2020 11:17:26 -0400 Original-Received: from [176.228.60.248] (port=4390 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kL6WK-0002ls-5p; Wed, 23 Sep 2020 11:17:26 -0400 In-Reply-To: (bug-gnu-emacs@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:188798 Archived-At: > Date: Tue, 22 Sep 2020 20:57:13 +0000 > From: Gregory Heytings via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > 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. > 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. > The attached patch makes it possible to (selectively) choose to display > the _first_ lines of the minibuffer instead of its _last_ lines (which is > and remains the default behavior). This means that displaying completion > candidates becomes a trivial task: it suffices to create an overlay with > completion candidates, without worrying at all about its size (or about > the size of the prompt and user input), and as many of these candidates as > possible will automatically be displayed. > > For example, implementing vertical icomplete only requires: > > (setq icomplete-separator "\n") > (add-hook 'icomplete-minibuffer-setup-hook (lambda () (setq start-display-at-beginning-of-minibuffer t))) I have a couple of comments regarding the proposed change: . How will Lisp programs decide when to set this flag and when not to set it? What would be the criteria? 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. . 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.