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: Sun, 20 Sep 2020 18:40:15 -0400 Message-ID: References: <83wo0p1twr.fsf@gnu.org> <83r1qx1q9v.fsf@gnu.org> <838sd425l2.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="36980"; 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 00:41:24 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 1kK81L-0009Ym-Tc for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 21 Sep 2020 00:41:24 +0200 Original-Received: from localhost ([::1]:48842 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kK81K-0008Tz-V3 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 20 Sep 2020 18:41:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40050) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kK810-0008TR-7p for bug-gnu-emacs@gnu.org; Sun, 20 Sep 2020 18:41:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41374) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kK80z-00022D-Ss for bug-gnu-emacs@gnu.org; Sun, 20 Sep 2020 18:41:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kK80z-000210-QY for bug-gnu-emacs@gnu.org; Sun, 20 Sep 2020 18:41:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 20 Sep 2020 22:41: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.16006416267696 (code B ref 43519); Sun, 20 Sep 2020 22:41:01 +0000 Original-Received: (at 43519) by debbugs.gnu.org; 20 Sep 2020 22:40:26 +0000 Original-Received: from localhost ([127.0.0.1]:52920 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kK80P-000203-SV for submit@debbugs.gnu.org; Sun, 20 Sep 2020 18:40:26 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:62521) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kK80N-0001ze-Tt for 43519@debbugs.gnu.org; Sun, 20 Sep 2020 18:40:24 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 949588096B; Sun, 20 Sep 2020 18:40:18 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id A2D2180BA9; Sun, 20 Sep 2020 18:40:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1600641616; bh=MKEz0MWWU/EUnpV3Eks6XmURyemVBGDdolqnhEi93lc=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=pbM2pVD+N2Sss7yAHbu2Vq6lXt0Zd9U68CpMJZB08t5ELOAmnl+VDRnFzvnB+XnAO 0I0sPOemE7/F30J57dQjkJrv7isnnZaRW8hnlPQvL8ySCBTdZZyxy6gNfqtdC5HGXa +mnBJiUD8kcgGD3v9XVAhZm3QCc97NwFAD7xccuq6P0F7OT0zDNbS1fK85vIBaNALk RlilkKKitWTNzAEpmUVqh3bgWgs0BxUmjib/17wBLInUl7AuStnd0DAp2B7UyPJS7H TtX9hGIeu48zaBW843AmDjIzSWOkeTqzHp5wn/yIWtuirbGhVszcRnTqZxR+9LlhLq txkhuMxkXD7Sg== Original-Received: from alfajor (unknown [45.72.232.131]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 6EB73120328; Sun, 20 Sep 2020 18:40:16 -0400 (EDT) In-Reply-To: <838sd425l2.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 20 Sep 2020 11:52:09 +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:188548 Archived-At: >> That the redisplay performed horizontal scrolling when it was not needed >> since the cursor was already visible without such scrolling. > 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. > The issue is with determining the > mini-window's start position. In the case with the overlay, we > compute that position as EOB, whereas in the case with buffer text, we > compute it to be at BOB. The reason is what I said: the very > different behavior of the move_it_* functions when they need to > traverse overlay strings. > > The basic logic of resize_mini_window is like this: > > . compute the number of screen lines required for displaying the > mini-window > . if the computed number of screen lines is more than > max-mini-window-height allows, then compute where to start the > mini-window display, as follows: > - start at the end of the stuff to be displayed in the mini-window > - move back max-mini-window-height screen lines > - use the start of the screen line where we wind up as the > mini-window's start point 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? >> So the question is: how to get the same behavior as what we'd get with >> `insert` but without actually modifying the buffer's contents? > You can't, not without redesigning the display code. At least not in > the general way you describe the issue, and not to the best of my > knowledge. 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. Stefan