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:46:18 +0000 Message-ID: References: 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="11613"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Alpine 2.22 (NEB 394 2020-01-19) Cc: 43572@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Sep 23 21:49:31 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 1kLAlf-0002wm-Ao for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 23 Sep 2020 21:49:31 +0200 Original-Received: from localhost ([::1]:52194 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kLAle-0006zX-Dg for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 23 Sep 2020 15:49:30 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42152) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kLAjG-00055i-Tw for bug-gnu-emacs@gnu.org; Wed, 23 Sep 2020 15:47:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54615) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kLAjG-0001mY-IV for bug-gnu-emacs@gnu.org; Wed, 23 Sep 2020 15:47:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kLAjG-00009x-GI for bug-gnu-emacs@gnu.org; Wed, 23 Sep 2020 15:47: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:47: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.1600890383539 (code B ref 43572); Wed, 23 Sep 2020 19:47:02 +0000 Original-Received: (at 43572) by debbugs.gnu.org; 23 Sep 2020 19:46:23 +0000 Original-Received: from localhost ([127.0.0.1]:37928 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kLAid-00008Z-FM for submit@debbugs.gnu.org; Wed, 23 Sep 2020 15:46:23 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:62029) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kLAic-00008R-2u for 43572@debbugs.gnu.org; Wed, 23 Sep 2020 15:46:23 -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 08NJkLJC008444 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 23 Sep 2020 19:46:21 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 08NJkbDs019443; Wed, 23 Sep 2020 19:46:37 GMT In-Reply-To: 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:188826 Archived-At: >> 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. > > You should update your recipe, because Eli's patch takes care of this > case already. > Indeed, but this recipe is what exists in Emacs 27.1 and what most people can try immediately. The "problem" with Eli's patch is that it takes care of 95% of the cases, and that the remaining 5% are more difficult to see, yet are there. > > I'm not completely sure which case(s) you're thinking of now that Eli's > patch handles the most common case we've seen so far. But maybe the > problem shows up when we have a minibuffer content that spans 2 lines, > in which case the redisplay will choose to show the last line (assuming > point is in the second line) plus icomplete's overlay rather whereas you > presumably would want to see both lines from the minibuffer (and hence > one line less from icomplete's overlay)? > Yes. See the recipe in my previous mail. If works with N lines, with N > 1. > > So a recipe could look something like: > > src/emacs -Q --eval '(setq max-mini-window-height 2)' -f icomplete-mode > C-x C-f lisp/progmodes/../progmodes/../progmodes/../progmodes/../progmodes/../progmodes/../progmodes/../progmodes/../progmodes/../ > > where we see the whole of icomplete's overlay rather than seeing the > whole of the minibuffer's actual content. > The problem is that such a recipe would only work with a not-too-wide Emacs frame and a not-too-small default font. For example, on my computer, it does not demonstrate the problem. > > In general both are perfectly valid choices and which one is best > depends on what is the intention behind the particular overlay and its > relation to the minibuffer's content, so indeed the redisplay would need > additional information in order to decide which behavior to choose. > I agree with you, which is why I think that ATM the best thing to do is just to make such a choice possible. > >> 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). > > Currently, the redisplay code focuses on making sure point is displayed. > In the resize_mini_widow code we try to accommodate some extra desires, > mostly in the form of giving more importance either to what's before > point or what's after it. > I don't think this is precise enough, but OTOH it's very hard to precisely define what happens. Currently resize_mini_window() sets "start" to max-mini-window-height lines before the end of the buffer (unless resize-mini-windows is nil, in which case "start" is set to BOB). The redisplay code takes that value; if point is not between start and EOB it overrides it, otherwise it displays the buffer between start and EOB. > >> The attached patch does not change the behavior of Emacs in any way, >> unless the feature it introduces is used. > > I see the following potential problem with it: icomplete will likely > want to set it globally, but that means it will also affect uses of the > mini window where icomplete is not used. Also, potential other users > may encounter similar difficulties. > No, if you look at the patch its value is reset to nil whenever the minibuffer is entered. And the example I gave with icomplete is: (add-hook 'icomplete-minibuffer-setup-hook (lambda () (setq start-display-at-beginning-of-minibuffer t))) where icomplete-minibuffer-setup-hook is run during minibuffer setup if (and only if) icomplete is active. So the behavior with M-: for example would not be affected. > > I don't have a patch to suggest, but I think ideally, I'd want clients > like icomplete to tell the redisplay either something like "please > display as much as possible of *this* chunk of text" or maybe "feel free > not to display all of this overlay, it's not super important". > Yes, that's the point. The patch I proposed tells redisplay "please display as much as possible of the text between BOB and point", when the current behavior tells redisplay "please display as much as possible of the text between point and EOB". Something more fine-grained would of course be possible, but I don't think it is a good idea to implement a feature when there is no clear need for it.