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: Tue, 01 Feb 2022 20:18:06 +0200 Message-ID: <83pmo678o1.fsf@gnu.org> References: <83y5ajmcwk.fsf@gnu.org> <83sj0rmat2.fsf@gnu.org> <83r4gbm991.fsf@gnu.org> <87czk87vmo.fsf@gnus.org> <87k0egwxk6.fsf@web.de> <83k0eg7y23.fsf@gnu.org> <87sft37nmo.fsf@web.de> <83a6fb90zy.fsf@gnu.org> <87h79j2srb.fsf@web.de> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40579"; 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 Tue Feb 01 21:32:38 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 1nEzpM-000AQh-Je for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 01 Feb 2022 21:32:36 +0100 Original-Received: from localhost ([::1]:51692 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nEzpL-0007lw-5h for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 01 Feb 2022 15:32:35 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:43424) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nExkR-0007UK-J9 for bug-gnu-emacs@gnu.org; Tue, 01 Feb 2022 13:19:24 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:51130) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nExk6-0000Cu-Dp for bug-gnu-emacs@gnu.org; Tue, 01 Feb 2022 13:19:23 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nExk6-0006zP-6h for bug-gnu-emacs@gnu.org; Tue, 01 Feb 2022 13:19:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 01 Feb 2022 18:19:02 +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.164373949726810 (code B ref 14582); Tue, 01 Feb 2022 18:19:02 +0000 Original-Received: (at 14582) by debbugs.gnu.org; 1 Feb 2022 18:18:17 +0000 Original-Received: from localhost ([127.0.0.1]:44033 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nExjN-0006yK-2D for submit@debbugs.gnu.org; Tue, 01 Feb 2022 13:18:17 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:36456) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nExjK-0006y6-CS for 14582@debbugs.gnu.org; Tue, 01 Feb 2022 13:18:15 -0500 Original-Received: from [2001:470:142:3::e] (port=46056 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 1nExjF-00007a-25; Tue, 01 Feb 2022 13:18:09 -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=CTy7QpE56QXMWAFSFgDy+vMufVwQ2SAqBjMYo6pFs64=; b=RpVHLPIiZAJP f4KwYoDRUJclDVd/vE3CDOEbS5ks9YN9D2KBF1b811mcImuzB14yWjVBytv6vX7Fc/T4A/j37XlYf oDRl2qJonbUsJcpQwulv2aC5hAmye39KGXkQ6KruEmtsO7DUxoJdrRETRnC6I9krW/jKdpW9LlOH1 LJaWYGCwBM36Fpuo3hQW9CIkzyDFLpd/wN3cdc9tKS2JyXjGWtAORkQbVwUqPRmGFXVG3xNGukeaG Bgr8NKvBw+QXQUQUoNCby9i518h+5lK3yP7Q0bgTW6r4ihW1SmDFXX5imaxFpm8Try4HXvtYQGgnA nrgQmdzUPqFQCB1GTcO5HA==; Original-Received: from [87.69.77.57] (port=3893 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 1nExjE-0006BB-Fj; Tue, 01 Feb 2022 13:18:08 -0500 In-Reply-To: <87h79j2srb.fsf@web.de> (message from Michael Heerdegen on Tue, 01 Feb 2022 04:03:04 +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:225761 Archived-At: > From: Michael Heerdegen > Cc: larsi@gnus.org, esabof@gmail.com, 14582@debbugs.gnu.org > Date: Tue, 01 Feb 2022 04:03:04 +0100 > > I think I mean the same. I guess the original recipe only explicitly > sets window-start to ensure the recipe reliably works regardless of the > number of display lines and such things. > > Anyway, this here works for me: > > Open emacs -Q (I'm in X), and evaluate (with M-:) the follow piece of code: > > #+begin_src emacs-lisp > (progn > (dotimes (_ 33) (insert "\ > \(defun foo () > 1 > 2)\n")) > (goto-char (point-max)) > (sit-for 1) > (scroll-down) > (sit-for 1) > (hs-minor-mode) > (hs-hide-all)) > #+end_src > > That gives me a display of *scratch* where the first visible window line > displays "...)" instead of expected "(defun xyz nil...)". Yes, it's basically the same issue. So please tell me: why do you expect Emacs to move the window-start so that the window displays starting at "(defun ...)" in the above case? What would be the trigger for making that change in the window-start position? It's a good-faith question. The display engine doesn't know anything about the semantics and the intended effect of hiding the bodies of the functions by putting the invisible property there; in fact, the display engine doesn't even know what a function's body is, nor where it begins and ends. The original window-start position was inside a function's body, and the call to hs-hide-all causes that position to be displayed as the ellipsis, that's all. There's nothing here to cause the display engine to move window-start. So it doesn't, because it, by design, tries not to move the window-start fixed as much as possible. Perhaps your mental model of redisplay is that it determines the window-start position _after_ it applies the various text properties and overlays, which affect what will be visible on display. In which case it would have noticed that after hiding the function bodies the visual line will start at "(defun ...", and would therefore start the window's display there. But that's not how redisplay works: it in fact first determines where to put window-start, and only after that redisplays the window using that window-start position. And if that causes the window-start position to be covered by some display or invisible property or some overlay, it's all fine from the POV of the display engine -- precisely _because_ it isn't any of its business to understand what those properties and overlays mean and what effect they want to produce. hs-minor-mode _does_ know what effect it wants to produce, so it's hs-minor-mode that needs to adjust window-start if it happens to wind up in the part of text that is about to be hidden on display.