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#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content Date: Mon, 21 Sep 2020 14:31:49 +0000 Message-ID: References: <83wo0p1twr.fsf@gnu.org> <83r1qx1q9v.fsf@gnu.org> <838sd425l2.fsf@gnu.org> <83zh5jxm37.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="19509"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Alpine 2.22 (NEB 394 2020-01-19) Cc: monnier@iro.umontreal.ca, 43519@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Sep 21 16:38:15 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 1kKMxL-0004ws-J4 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 21 Sep 2020 16:38:15 +0200 Original-Received: from localhost ([::1]:47390 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kKMxK-00010M-L8 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 21 Sep 2020 10:38:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48244) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kKMrK-0004PW-AE for bug-gnu-emacs@gnu.org; Mon, 21 Sep 2020 10:32:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44090) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kKMrJ-0004GK-Tq for bug-gnu-emacs@gnu.org; Mon, 21 Sep 2020 10:32:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kKMrJ-0006tk-Re for bug-gnu-emacs@gnu.org; Mon, 21 Sep 2020 10:32:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gregory Heytings Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Sep 2020 14:32:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43519 X-GNU-PR-Package: emacs Original-Received: via spool by 43519-submit@debbugs.gnu.org id=B43519.160069871426502 (code B ref 43519); Mon, 21 Sep 2020 14:32:01 +0000 Original-Received: (at 43519) by debbugs.gnu.org; 21 Sep 2020 14:31:54 +0000 Original-Received: from localhost ([127.0.0.1]:55636 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kKMrC-0006tO-BG for submit@debbugs.gnu.org; Mon, 21 Sep 2020 10:31:54 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:53569) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kKMrA-0006tF-Lx for 43519@debbugs.gnu.org; Mon, 21 Sep 2020 10:31:53 -0400 Original-Received: from sdf.org (IDENT:ghe@faeroes.freeshell.org [205.166.94.9]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 08LEVptA021561 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 21 Sep 2020 14:31:52 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 08LEW79m007049; Mon, 21 Sep 2020 14:32:07 GMT In-Reply-To: <83zh5jxm37.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:188593 Archived-At: >> More precisely, in this case height > max_height, so >> >> init_iterator (&it, w, ZV, ZV_BYTE, NULL, DEFAULT_FACE_ID); >> >> is called, followed by >> >> move_it_vertically_backward (&it, height - unit); >> >> which does nothing given that height == unit, so start is set to ZV. > > height == unit only when max_height = 1. But the same problem will > happen if max_height = 2 and the stuff we want to display takes more > than 2 screen lines, right? In those other cases, this code doesn't "do > nothing". > Yes of course, I was commenting under the assumtion that (setq max-mini-window-height 1), with which this thread started. Indeed the code does not "do nothing" when max_height is > 1. > >> What I would suggest is to add a user option to set start to BEGV when >> height > max_height, which is what is needed here. It would be reset to >> nil in read_minibuf() before calling minibuffer-setup-hook, and would >> be used in resize_mini_window() as follows: >> >> /* Compute a suitable window start. */ >> if (height > max_height && !EQ (Vstart_display_at_beginning_of_minibuffer, Qt)) > > First, I'm not yet convinced starting at BOB is always TRT. For > example, what if the prompt is very long and takes up more than one > screen line? > I tested this. In that case (with max_height = 1) starting at BOB is not a problem, because the display engine with override this and display the point. The prompt will be hidden, but this is expected. It would happen, say, when you are completing a file name in a sub-sub-sub-...-directory with max_height = 1. > > Second, it is not enough to set window-start to a particular buffer > position, we must also make sure the position of point will be visible > with that window-start. Otherwise, redisplay will override the > window-start we set. So, before setting this flag, the application will > still need some code to see if BOB is pertinent, i.e. consider the > resulting layout, which is something you wanted to avoid in the first > place. > Note that this case (starting display at BOB and having point outside of the resulting display area) is highly unlikely. When it happens, as you write, redisplay overrides the window-start that has been set here, and it's okay if it does. > > And finally, if a sufficiently generic solution that doesn't require > external knobs can be devised, I'd prefer doing TRT automatically, > without imposing such non-trivial settings on the application. > Yes, hence my second proposal, which checks height at EOB and at EOB-1.