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#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content Date: Mon, 21 Sep 2020 17:05:42 +0300 Message-ID: <83y2l3xm15.fsf@gnu.org> References: <83wo0p1twr.fsf@gnu.org> <83r1qx1q9v.fsf@gnu.org> <838sd425l2.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28467"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 43519@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 21 16:06:13 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 1kKMSK-0007GN-Pp for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 21 Sep 2020 16:06:12 +0200 Original-Received: from localhost ([::1]:52302 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kKMSJ-0003Y4-Q4 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 21 Sep 2020 10:06:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38260) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kKMSB-0003VI-1n for bug-gnu-emacs@gnu.org; Mon, 21 Sep 2020 10:06:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43950) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kKMSA-0008RO-OA for bug-gnu-emacs@gnu.org; Mon, 21 Sep 2020 10:06:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kKMSA-0003zy-JS for bug-gnu-emacs@gnu.org; Mon, 21 Sep 2020 10:06: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, 21 Sep 2020 14:06: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.160069715415353 (code B ref 43519); Mon, 21 Sep 2020 14:06:02 +0000 Original-Received: (at 43519) by debbugs.gnu.org; 21 Sep 2020 14:05:54 +0000 Original-Received: from localhost ([127.0.0.1]:55496 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kKMS1-0003zZ-JL for submit@debbugs.gnu.org; Mon, 21 Sep 2020 10:05:53 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:59570) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kKMS0-0003zM-2u for 43519@debbugs.gnu.org; Mon, 21 Sep 2020 10:05:52 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:57525) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kKMRu-0008Pz-Tk; Mon, 21 Sep 2020 10:05:46 -0400 Original-Received: from [176.228.60.248] (port=2438 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kKMRo-0002mC-Cz; Mon, 21 Sep 2020 10:05:46 -0400 In-Reply-To: (message from Stefan Monnier on Sun, 20 Sep 2020 18:40:15 -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:188580 Archived-At: > From: Stefan Monnier > Cc: 43519@debbugs.gnu.org > Date: Sun, 20 Sep 2020 18:40:15 -0400 > > > There's no horizontal scrolling. > > To the extent that window-start is not at BOL, I think this qualifies as > horizontal scrolling, but maybe horizontal scrolling has a more specific > meaning within the redisplay with which I'm not aware. We do have horizontal scrolling in Emacs: when lines are truncated. See auto-hscroll and scroll-left/right. That's what "horizontal scrolling" means to me in the context of Emacs. > Hmm... I think I'm beginning to see where the difficulty might be > coming from, but it's still quite fuzzy. In my mind I'd have expected > the code to work more along the lines of: > > - compute the number of screen lines required for displaying the > mini-window > - enlarge/shrink the window accordingly > - rely on the usual redisplay code for the rest (which may decide to > change window-start in order to keep point within view, but in > our current example(s) wouldn't need to do that). > > 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. 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. 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. > IIUC the problem only shows up because of the auto-resizing of the > minibuffer window, right? > Indeed if I replace > > (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. It doesn't mean the mini-window will always be a single screen line. The user or a Lisp program can resize it "by hand", and it will stay that way until manually resized again. Basically, disabling this means either the user doesn't care about what will be visible in the mini-window, or a Lisp program takes the responsibility of resizing the mini-window as needed. When resize-mini-windows is disabled, we always start the display at BOB. That might be the desired outcome in the particular case you used as the example, but as I wrote elsewhere, I'm not at all sure this is TRT for all of the use cases we are discussing: for example, what if the prompt is longer than a single screen line? Worse, with the stuff to display in the mini-window long enough, leaving the mini-window not resized will obscure large portions of that stuff, so this cure sounds to me worse than the disease. 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.