From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier 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 14:33:13 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40470"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) 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 20:34:36 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 1kL9bA-000APF-7P for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 23 Sep 2020 20:34:36 +0200 Original-Received: from localhost ([::1]:59580 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kL9b9-0000xw-8F for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 23 Sep 2020 14:34:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56248) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kL9ad-0000d0-Tw for bug-gnu-emacs@gnu.org; Wed, 23 Sep 2020 14:34:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54513) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kL9ac-0001BC-9z for bug-gnu-emacs@gnu.org; Wed, 23 Sep 2020 14:34:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kL9ac-00067C-6t for bug-gnu-emacs@gnu.org; Wed, 23 Sep 2020 14:34:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 Sep 2020 18:34: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.160088600623442 (code B ref 43572); Wed, 23 Sep 2020 18:34:02 +0000 Original-Received: (at 43572) by debbugs.gnu.org; 23 Sep 2020 18:33:26 +0000 Original-Received: from localhost ([127.0.0.1]:37826 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kL9a2-000662-8Z for submit@debbugs.gnu.org; Wed, 23 Sep 2020 14:33:26 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:61475) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kL9Zy-00065g-G5 for 43572@debbugs.gnu.org; Wed, 23 Sep 2020 14:33:25 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id BEC1C100031; Wed, 23 Sep 2020 14:33:16 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 38D9810022D; Wed, 23 Sep 2020 14:33:15 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1600885995; bh=cIzBg31Jbg0LObO0y/DdvmWglO3ucFXw0/8SEHDDjbY=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=SB3dzzwK2XyNHc/bEI75PXA+2T20XQgM+tVdwetYXr3S1EaIRB3mxC2vALIK2DXUI X6wwyqEEtis2bSMPN32/EXBcjk+0exNpuAsbGKGFLqrK8uPibK6ZrIRcvy1/RRzuZA rX+DuyEvKHn67Bp4aK9AkHKW2eDJ1UZNatOT8dJEI03W1p6cdyUVchnnieWDu12ftE LCWYLid5zo1I0NAqcjXsNH4hXQ5g/MjwQVOGQO8zNyfFhU4G/F56c8etvLNuYmsTPo KOoJnFzFBf6/NGniXvccynuiA/KKbfjbIrSKmPUk+H2i9qykb0/oFDzBl8c+jFxVwH jSL9386MfHLng== Original-Received: from alfajor (unknown [45.72.232.131]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 10A971204BC; Wed, 23 Sep 2020 14:33:15 -0400 (EDT) In-Reply-To: (Gregory Heytings's message of "Tue, 22 Sep 2020 20:57:13 +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:188817 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. 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)? 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. 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. > 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. > 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. 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". [ Note: "please display as much as possible of *this* chunk of text" is what I'd want to do in diff-mode when I move between chunks or in smerge-mode when I get to a new conflict, so maybe such a thing would make sense not just in the minibuffer. ] Stefan