From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii 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: Mon, 28 Sep 2020 09:20:30 +0300 Message-ID: <83pn66mngx.fsf@gnu.org> References: <83a6xguy7w.fsf@gnu.org> <83y2kztf9v.fsf@gnu.org> <83ft77t8kh.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4151"; mail-complaints-to="usenet@ciao.gmane.io" Cc: ghe@sdf.org, 43572@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Sep 28 08:21:28 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 1kMmXP-0000q9-AS for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 28 Sep 2020 08:21:27 +0200 Original-Received: from localhost ([::1]:52446 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kMmXK-0003VW-OK for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 28 Sep 2020 02:21:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39722) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kMmX0-0003VQ-Pg for bug-gnu-emacs@gnu.org; Mon, 28 Sep 2020 02:21:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39693) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kMmX0-00079y-Gp for bug-gnu-emacs@gnu.org; Mon, 28 Sep 2020 02:21:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kMmX0-00019r-Bm for bug-gnu-emacs@gnu.org; Mon, 28 Sep 2020 02:21:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 28 Sep 2020 06:21: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.16012740504411 (code B ref 43572); Mon, 28 Sep 2020 06:21:02 +0000 Original-Received: (at 43572) by debbugs.gnu.org; 28 Sep 2020 06:20:50 +0000 Original-Received: from localhost ([127.0.0.1]:51239 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kMmWo-000193-EG for submit@debbugs.gnu.org; Mon, 28 Sep 2020 02:20:50 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:32846) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kMmWn-00018q-46 for 43572@debbugs.gnu.org; Mon, 28 Sep 2020 02:20:49 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:37714) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kMmWh-00078y-SP; Mon, 28 Sep 2020 02:20:43 -0400 Original-Received: from [176.228.60.248] (port=2246 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kMmWh-0002qP-6k; Mon, 28 Sep 2020 02:20:43 -0400 In-Reply-To: (message from Stefan Monnier on Sun, 27 Sep 2020 17:59:02 -0400) 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:189181 Archived-At: > From: Stefan Monnier > Cc: ghe@sdf.org, 43572@debbugs.gnu.org > Date: Sun, 27 Sep 2020 17:59:02 -0400 > > >> IOW, by default if scrolling was needed anyway and scroll-conservatively > >> is not set, I'd expect "centered at point". > > The code which implements automatic scrolling was not written with the > > mini-window in mind. In fact, we would like not to allow any > > scrolling at all there. > > When the window is big enough to show the whole content, I agree, but as > soon as the buffer is bigger then we need to handle scrolling, just > like elsewhere. > > > So perhaps relying on scrolling could be fine in normal windows, it > > will most probably do the wrong thing in mini-windows. > > That's not my experience so far. I do find that the > `scroll-conservatively` is generally desired for the mini-window > (whereas I don't generally like it in normal windows), but other than > that I find (much to my surprise) that the generic scrolling code > behaves just as well as the ad-hoc scrolling code in resize_mini_window. Maybe it's 80% correct, but my worry is exactly those remaining 20%. It is they that generate most of the bug reports in Emacs nowadays. The fact that you find scroll-conservatively improve the results is already a clear sign that the scrolling mechanism is not fit very well for such small windows, especially when they are used for user interaction. And if you look at the window-display code, you will see there several code fragments dealing with the cases of a text line which is as tall or taller than the window, whose results are frankly questionable, and whose only justification is that those cases "should not happen". What you suggest will make the probability of that happening much higher, and in use cases where it will hurt. And all this is even before we take the massive use of overlay strings in some completion features. So no, I cannot agree that your experience is evidence good enough for allowing GP Emacs scrolling code to handle mini-window display. > Thinking about it, maybe I shouldn't be surprised: the generic code is > used much more often and has been tuned quite heavily over the years to > provide good behavior is the vast majority of cases, so it's only > "normal" that it should behave nicely in this case as well. That is true, but it wasn't tuned to the use cases we meet every day in the mini-windows. We generally don't allow a window to become too small in height, but that happens with mini-windows all the time.