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: Mon, 28 Feb 2022 15:10:16 +0200 Message-ID: <83r17nm91j.fsf@gnu.org> References: <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> <83tud5ssd4.fsf@gnu.org> <87bkzdj5h3.fsf@web.de> <83fsoosfvn.fsf@gnu.org> <87fsong0ii.fsf@web.de> <83leyfq9ff.fsf@gnu.org> <878rtx6k2t.fsf@web.de> <83v8x0ohp3.fsf@gnu.org> <87wnhfrj7b.fsf@web.de> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26605"; 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 Mon Feb 28 14:12:00 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 1nOfok-0006gL-S7 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 28 Feb 2022 14:11:59 +0100 Original-Received: from localhost ([::1]:59574 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nOfoj-0001NP-SI for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 28 Feb 2022 08:11:57 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:57300) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nOfnq-0000dR-AU for bug-gnu-emacs@gnu.org; Mon, 28 Feb 2022 08:11:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:38362) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nOfnq-0002y0-19 for bug-gnu-emacs@gnu.org; Mon, 28 Feb 2022 08:11:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nOfnp-0005KJ-SW for bug-gnu-emacs@gnu.org; Mon, 28 Feb 2022 08:11: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: Mon, 28 Feb 2022 13:11: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.164605383720441 (code B ref 14582); Mon, 28 Feb 2022 13:11:01 +0000 Original-Received: (at 14582) by debbugs.gnu.org; 28 Feb 2022 13:10:37 +0000 Original-Received: from localhost ([127.0.0.1]:60492 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nOfnR-0005Jd-3C for submit@debbugs.gnu.org; Mon, 28 Feb 2022 08:10:37 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:51362) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nOfnP-0005JO-7Y for 14582@debbugs.gnu.org; Mon, 28 Feb 2022 08:10:35 -0500 Original-Received: from [2001:470:142:3::e] (port=39410 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 1nOfnK-0002rW-1V; Mon, 28 Feb 2022 08:10:30 -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=+qjZmmVKokBPnanZf5QxAReFWansQHu/xa3dIdcQFzI=; b=YdeYGvBTbMQk NsQxiGS247Ht2p7A1ioHdtQb4CfDjAIapRaOmD+BcYrNXiD3ACbnbuQrXw+a8Dwnk90P3V7EmtV9W RX9tWVav/bf8Yo+eB3DmYUdBrZZLHXHWHwzMDPXs5jkbzHHaXIz9qB9K8iKMCRc+pfzYOWWuLVQdy iPtNO98brOLpNfLevOBQ7fpQhPgeero+RsiYxzY0SinY7VA1huRMzYVUv3if4DiY5Mosm+2yCZT6Z asDaPhYOBx5zvYi3YJ03KOfq5omeueN4u9dAqSgJlGpZdEfUFpjMe5TeOn1EKlRXs30x3+01LzkBs fuvnrczhm0Hiknr8/yma4w==; Original-Received: from [87.69.77.57] (port=4682 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 1nOfnG-0008Ch-5z; Mon, 28 Feb 2022 08:10:26 -0500 In-Reply-To: <87wnhfrj7b.fsf@web.de> (message from Michael Heerdegen on Mon, 28 Feb 2022 00:19:36 +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:227805 Archived-At: > From: Michael Heerdegen > Cc: larsi@gnus.org, esabof@gmail.com, 14582@debbugs.gnu.org > Date: Mon, 28 Feb 2022 00:19:36 +0100 > > Eli Zaretskii writes: > > > In the context of redisplay, any change of the window-start point is > > referred to as "scrolling the window". So when you tell the display > > engine to make sure the window-start is visible, and the last used > > window-start isn't, you cannot at the same time ask it not to scroll, > > because that's a contradiction. > > But when I said that using the new variable makes Emacs really scroll, > visually, not only in an abstract sense, didn't you say mean that was > unavoidable? I think we are having a terminological misunderstanding here. What do you mean by "really scroll", and how is it different from the other types of "scrolling", in your mental model of what we are discussing? I'm asking because it is not trivial to define "real scrolling". For example, suppose Emacs changes the window-start point, and then redraws each and every screen line from top of the window to its bottom -- do you consider this "real scrolling"? It may well appear to the user as scrolling, since every line moves up or down by the same number of screen lines. > > > And tell me that a solution without scrolling involved > > > is not possible, and why, or why you think that scrolling is > > > unavoidable. You said it can't be avoided when we do something in the > > > display engine. > > > > That's not what I said. Quote: > > > > 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. > > Recenter means actual, not only per definition scroll - right? No, not necessarily. Recentering in this context means Emacs calculates a new window-start position such that the line showing point will be centered in the window, and then redisplays the window using that window-start position. _How_ it redisplays the window is a separate question -- the display engine has several optimizations it will try to make redisplay as fast as possible, and some of these optimizations can be considered "real scrolling" (according to my interpretation of that term). > > I need a more concrete proposal to answer these questions. IOW, I > > don't think I understand what kind of solution do you have in mind > > here. > > I didn't make one since my knowledge here in inferior. Personally I > would adjust window-start from a hook and call `redisplay', which is > probably not the best solution. The question is how would you compute the new window-start? What happens after that, i.e. how the call to 'redisplay' redraws the window given a specific window-start position, you cannot control -- it could very well decide it wants to scroll the window. It's no accident that scroll commands in Emacs do precisely that: they compute a suitable window-start, and then let the display engine do its job under the restriction that it shall abide by that window-start position.