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: Fri, 25 Sep 2020 10:14:47 +0000 Message-ID: References: <83h7rov7xy.fsf@gnu.org> <837dskuvx3.fsf@gnu.org> <833637uubc.fsf@gnu.org> <83mu1ftdkb.fsf@gnu.org> <83imc3tach.fsf@gnu.org> <83eemrt8da.fsf@gnu.org> <838scytk87.fsf@gnu.org> <835z82tdz9.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="16173"; 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 Fri Sep 25 12:15:12 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 1kLkkx-00047E-RV for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 25 Sep 2020 12:15:11 +0200 Original-Received: from localhost ([::1]:41404 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kLkkw-00009t-Te for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 25 Sep 2020 06:15:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42074) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kLkkp-000086-4N for bug-gnu-emacs@gnu.org; Fri, 25 Sep 2020 06:15:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:59444) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kLkko-000733-PC for bug-gnu-emacs@gnu.org; Fri, 25 Sep 2020 06:15:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kLkko-0001bd-G1 for bug-gnu-emacs@gnu.org; Fri, 25 Sep 2020 06:15: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: Fri, 25 Sep 2020 10:15: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.16010288946146 (code B ref 43572); Fri, 25 Sep 2020 10:15:02 +0000 Original-Received: (at 43572) by debbugs.gnu.org; 25 Sep 2020 10:14:54 +0000 Original-Received: from localhost ([127.0.0.1]:42757 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kLkkg-0001b4-8N for submit@debbugs.gnu.org; Fri, 25 Sep 2020 06:14:54 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:50917) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kLkkd-0001av-Mb for 43572@debbugs.gnu.org; Fri, 25 Sep 2020 06:14:52 -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 08PAEodm022102 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Fri, 25 Sep 2020 10:14:50 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 08PAF4Ie014435; Fri, 25 Sep 2020 10:15:04 GMT In-Reply-To: <835z82tdz9.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:188942 Archived-At: >> In fact these changes are, IMO, very regrettable, because they solve >> 95% of the problems that have been discussed in bug#24293, bug#39379, >> bug#43519 and bug#43572 (and perhaps others), and the remaining 5% will >> have to be solved another way (by text properties if that's what you >> agree on with Stefan). > > They solve the issue pointed out by Stefan in bug#43519. That they, by > sheer luck, also solve some of the other issues is just that -- sheer > luck. I don't claim and didn't intend to solve all the problems, in > particular the issue discussed in this bug report. They are related, > but different issues. > There have been several misunderstandings in these discussions. In bug#43519, Stefan pointed out an issue with a simple recipe to exhibit a more general problem. This simple recipe, because it was simple, did not demonstrate all aspects of the problem. In particular, it only demonstrated what he called "horizontal scrolling", when the problem in fact involves both horizontal _and vertical_ scrolling. I'll remind a second time the discussion on emacs-devel that prompted Stefan to file bug#43519: Ergus: [To implement icomplete-vertical] we need to add the exact amount of lines as accurate[ly] as possible. Stefan: I *strongly* recommend you design the behavior under the assumption that it's OK if there are a few more lines in the (mini)buffer than are actually visible. Me: If there are too many candidates the prompt disappears, leaving the cursor at the beginning of the minibuffer, which is counterintuitive. A simple example: after (setq max-mini-window-height 1), with "M-x a" the "M-x" prompt and the "a" disappear. Stefan: That can (and should) be fixed without having to reduce the number of candidates inserted in the (mini)buffer. Ergus: It will be great if you give me an idea about how to do that. Stefan: You need to figure out why the redisplay decides to hide the prompt rather than some other part of the (mini)buffer. Stefan files bug#43519 (with the "M-x a" example). As you see, the point is to keep the prompt visible, not just to avoid horizontal scrolling. And Stefan refers to bug#24293 and bug#39379, where the same problem (the prompt becomes invisible) is explained and workarounds are discussed. >> I don't think you will do this, but please, please: revert these >> changes. > > Reverting those changes would be a very strange thing to do. Those > changes solve a specific problem, and they solve it cleanly. > They partially solve a specific problem. This specific problem exists only in the context of inserting completion candidates at EOB with an overlay. And the specific problem is not horizontal scrolling, the specific problem is the prompt that becomes invisible. I clearly said (and explained) in bug#43519 that to solve that problem it is necessary to start display at BOB, and you preferred to implement a change that starts display at BOL. I think these changes are misleading.