From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu Newsgroups: gmane.emacs.devel Subject: Re: Allowing point to be outside the window? Date: Thu, 09 Dec 2021 20:19:13 +0800 Message-ID: <874k7ias3i.fsf@yahoo.com> References: <87ilwd7zaq.fsf.ref@yahoo.com> <83bl24yaed.fsf@gnu.org> <87sfvg7l51.fsf@yahoo.com> <83zgpowu23.fsf@gnu.org> <87zgpo5tws.fsf@yahoo.com> <83pmqkwi6r.fsf@gnu.org> <87v90c5su6.fsf@yahoo.com> <83o864wg2a.fsf@gnu.org> <87ilwb68ck.fsf@yahoo.com> <83zgpnunfo.fsf@gnu.org> <87fsrf3xmd.fsf@yahoo.com> <83y257ulfp.fsf@gnu.org> <8735ne4e0e.fsf@yahoo.com> <87czmcvcs1.fsf@yahoo.com> <83sfv85y36.fsf@gnu.org> <87v904tsvv.fsf@yahoo.com> <83h7bo5m1x.fsf@gnu.org> <87ilw3ubfp.fsf@yahoo.com> <83h7bn4e55.fsf@gnu.org> <877dcipjmk.fsf@yahoo.com> <835yryuhmo.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="13893"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (gnu/linux) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 09 13:31:31 2021 Return-path: Envelope-to: ged-emacs-devel@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 1mvIaB-0003O3-4A for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Dec 2021 13:31:31 +0100 Original-Received: from localhost ([::1]:34526 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mvIa9-0001c2-0K for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Dec 2021 07:31:29 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:38658) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mvIYI-0000bg-6c for emacs-devel@gnu.org; Thu, 09 Dec 2021 07:29:34 -0500 Original-Received: from sonic302-21.consmr.mail.ne1.yahoo.com ([66.163.186.147]:39015) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mvIY9-0004bd-J1 for emacs-devel@gnu.org; Thu, 09 Dec 2021 07:29:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639052963; bh=/Iq3/jezWT+dd/Y+ccvtD24dj7ZtOMDV6EgkTi2/du8=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=JPrMb1bbfEO8RDrLdRQT/Q3hUdzEHLzz46VnpoNrJg3U9H//0JFrnutsmnSjMwq/fXs2UmN8uABOtJ+NxlzhgHR/qaEJwalHJ9fvsr9S/+Ip5IkIIqLxbLsNToNKcEsj7lYy/S1emakyPY57smRqmfQOWggV/WSEX2AZPgHlTZz5DWhBE6DXF3TqOpZQ3UXvjZmBTfujsgSSynMLh/ClLpBZiZ5V7jbvq3AfCiDInzGrZ2V3I1ne9enQ4Q2Rr91gTbCur0FLdJavohqPi3tYnV7qmm8koIIDftDbVkDPfUQg0WG1w1TzTFJl/hJRHgzH+F8+xRlj6lRUMC50OudVHw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639052963; bh=eIDBbJFWNptn47+r92Cl0/fxwTwSgTVA5YvlEoznKWz=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=XKq/MMPnlZt6DkO2vcOZVVfiK6uqaEjB8PvSmdzH9Ra1BQur/k3ZU5Q/ep3FDWxkSkrUpd+iWlsh254zw/RtfkxEMl3fESy3t6gSf36CIzQxsyGhRR53O1t+JZb2sjYwqVKVPDtByzbOBVdEhcz92hcNK9na5FsyBFrMf+GwHGoZI0qyWV18+WqIGt4JVVzCYroCxvAnlUenHIN9ESsv1cJR/RnulwYSL3ltZjDc1uyxh4FBIi8R49liJcALRXmmk9Jq9IZvHsjVnpBsoF+yXOZ4NCZm5dfhPQupmgLBi5Q32UH/jT1Eu6HdkCFkoDSs2Jun+qtnI//a+WmjOBEDRA== X-YMail-OSG: Vzje.zgVM1nLNF3Y88Evmtbe5t5HfLx.8w7xpOpTwPPGf61ZierulBv6OxJkqCZ wzLCi4nqu89Wae4wxKuYOb5lh9.AUBNBXEl0vzPaz.6mC3gfSm5R_jxViUvgNOQ16Ho0erfQHj3N M.GRaAet4WSEDxNfCApAq8yLEprPTuwyYRG0UdZ4K6nCkYhVhHUfcFhUZWdjvrPwIUUTAivOE3zF _W6C7x.NWCoB83V3fNFllCQnMMJMoHRKNewX1VwXNrN8blpOE_jzuwXvy2SFg1HP_Wt.RhvmnhxD aFnk3lO3nheFkorVBUadI5R5n5rCgcFR452CG7d9_7lmBrUWOMXPo95pMNApgAwPIFZXjEOTMFOK CF5WdA7hJz.bn5i8CyaibKFcjRGRHW8jZLBVqQiHATuz7i_OWo4zBNpImbBGTb2Co0MDWekIzgVp o_D9Fa9GbsaEViIzsbP9Lc7VJqkYvCwLmylZTL11bfYjRAenVHOiqZP88qcdW7WPExaKqg.TpzoL ameeV3dWGZIpeM2iLjRJooqBzCkCkYwLgOCLK1H5S2CSFS6EgLvNpFLqEdrKXkbPpiEg09bFIovE B.i_srp3AJK7V6mpeTj4bvMr7wOCMjCfyExiu6LbcuR9hzXvs8tDuAEtghprQZPPM3aT_j0UQlmd _gSPZyzyKYXvrCXMg_IK2kMYYd_TmXGtZS5C1ORGwqEpLKve5tscQa6.0MgxIBIWJud8Pky1L_sz jc8DpoXpZqLEo4hpD5pRn9jFvtZQy55bfyvFYD55yfwIMABYM4PfxNWu9NH3LouYERvKilJYETFa PgWrsCIwqWETGABusDL6aQjBBmBmO6kEPudadKf27Y X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ne1.yahoo.com with HTTP; Thu, 9 Dec 2021 12:29:23 +0000 Original-Received: by kubenode502.mail-prod1.omega.sg3.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID f48a411028371d55faaf91cb44138937; Thu, 09 Dec 2021 12:19:19 +0000 (UTC) In-Reply-To: <835yryuhmo.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 09 Dec 2021 13:45:03 +0200") X-Mailer: WebService/1.1.19306 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Received-SPF: pass client-ip=66.163.186.147; envelope-from=luangruo@yahoo.com; helo=sonic302-21.consmr.mail.ne1.yahoo.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:281485 Archived-At: Eli Zaretskii writes: > Once again, it's hard to understand the main ideas behind the > feature. You explained above when it brings point into the view, but > what I'm looking for is an explanation for how to modify > redisplay_window when this feature is turned ON, without losing too > much of the existing redisplay functionality. The idea is to prevent redisplay_window from entering `recenter' unless `w->force_start' or a few other conditions are true, and to not display the phys cursor if its position is unknown. A large part of `try_scrolling' is also disabled, but I think I know how to turn it on now. > Also, a large part of the patch seems to change mainly whitespace, so > please use the -w switch to show diffs ignoring the whitespace > changes, because otherwise it's very hard to spot the real changes. Thanks, I will keep that in mind in the future. > A couple of comments below: >> --- a/src/window.c >> +++ b/src/window.c >> @@ -5576,7 +5576,8 @@ window_scroll_pixel_based (Lisp_Object window, int n, bool whole, bool noerror) > It seems you made changes for GUI scrolling, but not for TTY > scrolling? Is this feature supposed to be disabled on TTY frames? No, it's something I plan to do in a while, but not yet. >> @@ -17768,6 +17770,9 @@ try_scrolling (Lisp_Object window, bool just_this_one_p, >> else >> scroll_max = 0; >> >> + if (!keep_point_visible) >> + goto out; >> + >> too_near_end: > I'm confused here. This bypasses all of try_scrolling's code, which > can select a new window-start because, for example, point moved out of > the visible portion of the window. Does this mean that when > this feature is turned ON, scrolling of the window in these cases is > no longer supported? For example, let's say I pressed C-n and that > moved point below the window's end (with the default zero value of > scroll-margin) -- does it mean the window will not scroll, leaving > point invisible in this case? It does not: it enters the code under the `recenter' label instead, which causes point to be displayed at the center of the screen. But the behavior is very different between that and the code in try_scrolling, so I think it should be turned on if the numeric value of point has changed, as we do with the recenter label. >> @@ -18183,6 +18190,10 @@ try_cursor_movement (Lisp_Object window, struct text_pos startp, >> return rc; >> #endif >> >> + /* TODO: enable this optimization. */ >> + if (!keep_point_visible) >> + return CURSOR_MOVEMENT_CANNOT_BE_USED; > Likewise here: you are disabling one of the more important redisplay > optimizations, which minimizes redisplay work when the user just move > point a little ways. Can you tell why this needs to be disabled under > the new behavior? it seems to be unrelated, because the optimization > only does its thing when point didn't leave the window. I disabled all the redisplay optimizations when first developing this feature, so I could turn them on one-by-one to see if they would cause any problems. This optimization works fine however, so it can be enabled. > This will have to go eventually, as this trace is not useful in > general. Thanks, I'll keep that in mind. > This optimization also doesn't necessarily have anything to do with > point being outside of the window. That's because I haven't tested to see if it works yet. Thanks.