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#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content Date: Mon, 21 Sep 2020 13:25:01 -0400 Message-ID: References: <83wo0p1twr.fsf@gnu.org> <83r1qx1q9v.fsf@gnu.org> <838sd425l2.fsf@gnu.org> <83y2l3xm15.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23180"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 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 19:26:16 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 1kKPZv-0005tn-Lb for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 21 Sep 2020 19:26:16 +0200 Original-Received: from localhost ([::1]:47040 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kKPZu-0003eM-Nf for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 21 Sep 2020 13:26:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42500) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kKPZi-0003d8-Ij for bug-gnu-emacs@gnu.org; Mon, 21 Sep 2020 13:26:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44526) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kKPZi-0006lI-9Y for bug-gnu-emacs@gnu.org; Mon, 21 Sep 2020 13:26:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kKPZi-00035h-6Y for bug-gnu-emacs@gnu.org; Mon, 21 Sep 2020 13:26: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: Mon, 21 Sep 2020 17:26:02 +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.160070911311804 (code B ref 43519); Mon, 21 Sep 2020 17:26:02 +0000 Original-Received: (at 43519) by debbugs.gnu.org; 21 Sep 2020 17:25:13 +0000 Original-Received: from localhost ([127.0.0.1]:56068 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kKPYv-00034K-GK for submit@debbugs.gnu.org; Mon, 21 Sep 2020 13:25:13 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:10646) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kKPYs-000343-CZ for 43519@debbugs.gnu.org; Mon, 21 Sep 2020 13:25:12 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id B1E5C100234; Mon, 21 Sep 2020 13:25:04 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0B02B100019; Mon, 21 Sep 2020 13:25:03 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1600709103; bh=yJih/gA+Ovs6mu/7mobzZh+zhKvrwOA5eyvSQBgOzsk=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=XABaML4V5xL1/shuKcSYd9xYxHaHvdORs52pgWfyAP3OtUvICsK1MrSSZTFVnHHQ4 ee1SNsnuVVzYizSSbyyfo2+cHs/rW2YWrbdpBpZM7IoJEdCbQfqiSa67dJ2lEYe/kK DveC2VAlbdjRvSL+6RVBx0TfjZnc528TsUQ0J6h8CGVvDdOTu1Jv7suWDcKa2p8Pkr P9KHbjg6jGMNbge7az+g/OvzwHYgG55ewQyz3F+InX4KG7NtDphb48MElSpDAnMTTz AlFQdQhVm+ouLo127LRbbrITNQoMGr+c82z4isgWXD1inaoejCHu2eTcKF5+PCNdzl dW1lV3fWUJoJQ== Original-Received: from alfajor (unknown [45.72.232.131]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id AD691120264; Mon, 21 Sep 2020 13:25:02 -0400 (EDT) In-Reply-To: <83y2l3xm15.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 21 Sep 2020 17:05:42 +0300") 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:188622 Archived-At: >> Do you know why we don't do it this way, IOW why don't we first try to >> keep window-start unchanged and see if point ends up within view? > Because this way we have no control on where the mini-window's display > will start, and consequently what will be visible in the mini-window. Indeed, then we'll just rely on the "generic" behavior, which is admittedly not focused on single-line (or few lines) windows, but at least in the current case it works better (and simplifies the code slightly). > In particular, if point is at EOB, redisplay could (and normally does) > decide not to position point on the last screen line of the window, > which means we may have some of the text not visible for no good > reason -- not a good thing when user interaction is concerned. Not sure I understand what you mean. If point is at EOB, redisplay will make sure EOB is visible. Or do you mean a situation like: - minibuffer holds "foo\n" - the mini window is a single line - point is at EOB In which case we'd end up displaying the empty line instead of display "foo"? AFAICT our ad-hoc scrolling code gives the same result as the generic scrolling code in that case. I've been trying out the patch below and haven't bumped into any surprising behavior yet, but admittedly, I probably lack creativity. > More generally, since the mini-window is usually small and user > interaction requires to make sure the user sees the important parts of > the buffer text (if not all of it), we want tighter control on what > will end up on display, and the way to do that is via setting > window-start. That makes sense in general, but I'm curious to see what are the concrete cases where our "generic" scrolling logic leads to worse behavior than the ad-hoc one used here. So far the patch below fixed the original problem and I haven't been able to see any regression yet. >> (setq max-mini-window-height 1) >> with >> (setq resize-mini-windows nil) >> the problem doesn't appear, even though resizing is in fact disabled in >> both cases. > Disabling resize-mini-windows means the mini-window is not resized at > all as part of redisplay. Yes, of course, I was just using it to illustrate what happens when we don't use the ad-hoc scrolling code from resize_mini_window in the case where there is in practice no resizing anyway. > And besides, this is a user option, so having some code disregard it > is unfriendly, to say the least, even if we do that temporarily. Oh yes, Stefan diff --git a/src/xdisp.c b/src/xdisp.c index dfcb1d73e4..b25aa07f1f 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -11885,14 +11885,18 @@ resize_mini_window (struct window *w, bool exact_p) if (height > max_height) { height = (max_height / unit) * unit; - init_iterator (&it, w, ZV, ZV_BYTE, NULL, DEFAULT_FACE_ID); - move_it_vertically_backward (&it, height - unit); - start = it.current.pos; + /* bug#43519: Let the redisplay choose the window start! + * + * init_iterator (&it, w, ZV, ZV_BYTE, NULL, DEFAULT_FACE_ID); + * move_it_vertically_backward (&it, height - unit); + * start = it.current.pos; */ } else - SET_TEXT_POS (start, BEGV, BEGV_BYTE); + { + SET_TEXT_POS (start, BEGV, BEGV_BYTE); - SET_MARKER_FROM_TEXT_POS (w->start, start); + SET_MARKER_FROM_TEXT_POS (w->start, start); + } if (EQ (Vresize_mini_windows, Qgrow_only)) {