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#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay. Date: Fri, 11 Feb 2022 10:46:31 +0200 Message-ID: <83tud5ssd4.fsf@gnu.org> References: <83a6fb90zy.fsf@gnu.org> <87h79j2srb.fsf@web.de> <83pmo678o1.fsf@gnu.org> <87iltynkbg.fsf@web.de> <83h79i6iw6.fsf@gnu.org> <878rut6hlq.fsf@web.de> <83czk578m0.fsf@gnu.org> <837dab4zmm.fsf@gnu.org> <875ypvcsyf.fsf@web.de> <83k0ea3fci.fsf@gnu.org> <87r18gn1rh.fsf@web.de> <83k0e8z3uo.fsf@gnu.org> <87k0e6xkta.fsf@web.de> <83v8xqvxox.fsf@gnu.org> <87r18ej957.fsf@web.de> <83r18dwnqn.fsf@gnu.org> <875ypor90e.fsf@web.de> <83wni4up6g.fsf@gnu.org> <87pmnvr0l4.fsf@web.de> <83a6ezuu00.fsf@gnu.org> <87wni2ypx7.fsf@web.de> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22863"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, esabof@gmail.com, 14582@debbugs.gnu.org To: Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Feb 11 09:47:35 2022 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 1nIRaZ-0005m2-4B for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 11 Feb 2022 09:47:35 +0100 Original-Received: from localhost ([::1]:48646 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nIRaY-0002T7-1G for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 11 Feb 2022 03:47:34 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:39906) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nIRa2-0002Qg-5D for bug-gnu-emacs@gnu.org; Fri, 11 Feb 2022 03:47:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36103) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nIRa1-0004Ju-RM for bug-gnu-emacs@gnu.org; Fri, 11 Feb 2022 03:47:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nIRa1-0001wS-QU for bug-gnu-emacs@gnu.org; Fri, 11 Feb 2022 03:47:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 11 Feb 2022 08:47:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 14582 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 14582-submit@debbugs.gnu.org id=B14582.16445692037441 (code B ref 14582); Fri, 11 Feb 2022 08:47:01 +0000 Original-Received: (at 14582) by debbugs.gnu.org; 11 Feb 2022 08:46:43 +0000 Original-Received: from localhost ([127.0.0.1]:58233 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nIRZj-0001vx-4O for submit@debbugs.gnu.org; Fri, 11 Feb 2022 03:46:43 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:33072) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nIRZh-0001vi-9Y for 14582@debbugs.gnu.org; Fri, 11 Feb 2022 03:46:41 -0500 Original-Received: from [2001:470:142:3::e] (port=47314 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nIRZb-0004Ga-TD; Fri, 11 Feb 2022 03:46:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=ON0QXWEcfLhiHZLUt+p/xs+sQg6nkg3fh4hJFsBjKNM=; b=TrGxsIbrct3L 8Rm7/NjHFxtvP5Vi8kfdj9NXGfIrLUvKKe/qAGSu3bt8oU7jKUSzne6dz1+khIduYXqs3Y1K8qtlm IKs9aXA0Av86tg4+Y2NiDRBuOefIufTOs7uheOU8+XjdIWmDKf9LAk9ORbepzzax0A8AX0Nxz98oT TvTTPvtB5ip+OvnL83xiVcMk0kR7JRt7Y9HKwPUe2LCF/BCfIryT2O1LVDACfmDuN2pOIpB/DIiqj GKrQhmGSjwv7McCNfm/9sWSwnryBigpv5rgQFDScXQE0r7yIgnHYcM9WAyW5n6Tp2JZLsZI0egcXv RU/4iXTTXqMl8jc7z2iujg==; Original-Received: from [87.69.77.57] (port=4818 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nIRZb-0004FQ-CN; Fri, 11 Feb 2022 03:46:35 -0500 In-Reply-To: <87wni2ypx7.fsf@web.de> (message from Michael Heerdegen on Fri, 11 Feb 2022 05:42:44 +0100) 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:226655 Archived-At: > From: Michael Heerdegen > Cc: larsi@gnus.org, esabof@gmail.com, 14582@debbugs.gnu.org > Date: Fri, 11 Feb 2022 05:42:44 +0100 > > Eli Zaretskii writes: > > > That's not what make-window-start-visible means. It means "if the > > current window-start is invisible, try to find an alternative > > window-start that would be visible, while still showing point". > > > > Your interpretation of the setting is simply impossible to implement: > > the display engine cannot possibly do anything to uncover the hidden > > window-start point without scrolling the window in some way. So > > _something_ that was visible before must become invisible after, > > because we scroll the window. > > I'm irritated that the newly chosen window-start can be after the > original position. I don't know any use case where this is useful, and > it was only irritating whenever it happened in my test. Is this > unavoidable? It isn't unavoidable, but doing something more sophisticated would call for a significantly more complex code. The current solution for when this variable is set and the window-start point is invisible is very simple: we recenter the window around point. The recentering method is safe, because it always succeeds, which is why it also serves as the fallback method of finding the suitable window-start for redisplaying a window. The code that implements the recentering was already there, so the introduction of this new variable boiled down to recognizing the conditions under which we should go directly to recentering, bypassing all the other methods. Anything else would mean a much deeper surgery on the (already non-trivially complex) logic of redisplaying a window, whereby we both verify that the previous window-start is still usable, and try various optimizations to make the redrawing itself as cheap as possible. > BTW, why does the adjustment happen when I just move the cursor inside > the displayed window content without causing any display change? The > new heuristic seems to depend on the value of `point' (I don't mean > values that would cause scrolling the normal way). You may be unaware, but moving point always triggers redisplay of the window. That eventually nothing happens on the screen except showing the cursor at a different location is because Emacs is smart enough to detect that nothing else needs to change. IOW, it's not like redisplay is being explicitly told that only point moved, and moved slightly enough to allow the same window-start to be used, it has to deduce that by itself. When this new variable is set, and the window-start is hidden, Emacs falls back on recentering the window around point. If point is closer to BOB than half the window, recentering will normally fail to find a better window-start that would show point at the center of the window, but when point is farther than half the window, Emacs will scroll the window as result of recentering. That's why you see the dependance on point position. Once again, this option was intended to be used in relatively rare situations. I do not recommend to set it by default, especially if the side effects annoy you.