From unknown Sun Jun 15 08:58:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#64724: 30.0.50; Inconsistency between manual, comments in the code, and implementation of point adjustment Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 19 Jul 2023 07:03:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 64724 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 64724@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.168975014715667 (code B ref -1); Wed, 19 Jul 2023 07:03:01 +0000 Received: (at submit) by debbugs.gnu.org; 19 Jul 2023 07:02:27 +0000 Received: from localhost ([127.0.0.1]:54828 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qM1Cd-00044c-7E for submit@debbugs.gnu.org; Wed, 19 Jul 2023 03:02:27 -0400 Received: from lists.gnu.org ([2001:470:142::17]:57616) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qM1CY-00044K-Dq for submit@debbugs.gnu.org; Wed, 19 Jul 2023 03:02:25 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qM1CS-0006Om-Hm for bug-gnu-emacs@gnu.org; Wed, 19 Jul 2023 03:02:16 -0400 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qM1CP-0006GP-Kv for bug-gnu-emacs@gnu.org; Wed, 19 Jul 2023 03:02:16 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 404C1240103 for ; Wed, 19 Jul 2023 09:02:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1689750131; bh=sgojNXFD/cvuVCQgBUnoaLZdgViBHYOoHTKwaPXFTg4=; h=From:To:Subject:Date:Message-ID:MIME-Version:From; b=okbLoIX8aXITNTfKqmI2dEpWMbzMFMH3rFNQM8Gs4zPNF80NNVxCqshDEv3lQXeoL vW50e7zGINWSW70uLwvklHTeejgERShwgl2PnpNulnZ9kyXPx5I4eKBmuWOMM3256G QZtsBw9AOvCVjLlSJKvdrMIunrhhDyCIkbDzte2ODpiIyvm/8I6+vP/cpmE8mMm2IQ zxlWqMNPmtB72nfNDT6GYCRgWP/pLcNAdRkTFP8D8b1PZg4pCiBp90nmAjOpUX6JTS TpPZXFmhWOSTs40+wzj0HqNe8zCkaLoyg2jXoAdK86e9uYab4gLMIR92KwjcZoisqj piN+LiHq9fZaw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4R5RZp4Gs7z9rxG for ; Wed, 19 Jul 2023 09:02:10 +0200 (CEST) From: Ihor Radchenko Date: Wed, 19 Jul 2023 07:02:21 +0000 Message-ID: <87bkg81j0i.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Hi, This is a followup of https://orgmode.org/list/87ilag1pth.fsf@localhost We recently ran into some subtleties of point adjustment near invisible regions with sticky 'invisible property. The actual code in `set_point_both' makes sure to move point across invisible sticky region if point happens to end up right before front sticky invisible or right after rear sticky invisible region. However, 22.6 Adjusting Point After Commands does not mention this scenario. Further, `set_point_both' contains the following comments: /* If the preceding character is both intangible and invisible, and the invisible property is `rear-sticky', perturb it so that the search starts one character earlier -- this ensures that point can never move to the end of an invisible/ intangible/rear-sticky region. */ charpos = adjust_for_invis_intang (charpos, -1, -1, 1); <...> /* If the following character is both intangible and invisible, and the invisible property is `front-sticky', perturb it so that the search starts one character later -- this ensures that point can never move to the beginning of an invisible/intangible/front-sticky region. */ charpos = adjust_for_invis_intang (charpos, 0, 1, 1); However, 'intanglible text property is, in fact, not necessary to trigger the adjustment. May you (1) document this behaviour in the manual; (2) clarify what's up with intanglible. In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38, cairo version 1.17.8) of 2023-07-18 built on localhost Repository revision: aba3d13ea8d712bca1b3f23ac7db7e38c2165b3c Repository branch: feature/named-lambdas Windowing system distributor 'The X.Org Foundation', version 11.0.12101008 System Description: Gentoo Linux -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From unknown Sun Jun 15 08:58:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#64724: 30.0.50; Inconsistency between manual, comments in the code, and implementation of point adjustment Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 19 Jul 2023 16:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64724 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ihor Radchenko , Stefan Monnier Cc: 64724@debbugs.gnu.org Received: via spool by 64724-submit@debbugs.gnu.org id=B64724.16897849849135 (code B ref 64724); Wed, 19 Jul 2023 16:44:02 +0000 Received: (at 64724) by debbugs.gnu.org; 19 Jul 2023 16:43:04 +0000 Received: from localhost ([127.0.0.1]:57058 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMAGV-0002NG-PM for submit@debbugs.gnu.org; Wed, 19 Jul 2023 12:43:04 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37720) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMAGO-0002Mg-Qi for 64724@debbugs.gnu.org; Wed, 19 Jul 2023 12:43:02 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qMAGI-0001zg-RH; Wed, 19 Jul 2023 12:42:50 -0400 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=AJT/1iSGATu9NhIJGBOnieNj6TmMTPUzEC4jbPFwyWs=; b=MhPaflUVG9i/ r30P1sNpyZawU846+WRwfbzBKmXFti2eixU/nIxE+BWPmFe8ZBd1oBkYYjq4j74D9vmYRLHkugsAF /7RmVHUOb/wo9qaHitMZzwnBJtXFS3BQjSg4jyV415R1m1KviOYTs0rQiIJcQX2vYx6B5nh2IL7Rq hqflxNHo88j06ypMsbhLxwmy+WvZ2hlCjWNjr72Ch8XTYi1XPKL7+x2z5j3MCv09A3878DWjwRC43 rbLw5dhMtzoyY8ECZa/QelDFosnxp475bD76nMn/o3j2MCCgzVBa7Frioys+G7IxR7Hcn4NUFggt0 wGMfOnjiXe6hdMWzkWiMjA==; Received: from [87.69.77.57] (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 1qMAGI-0006g0-Az; Wed, 19 Jul 2023 12:42:50 -0400 Date: Wed, 19 Jul 2023 19:43:21 +0300 Message-Id: <83fs5j4zti.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87bkg81j0i.fsf@localhost> (message from Ihor Radchenko on Wed, 19 Jul 2023 07:02:21 +0000) References: <87bkg81j0i.fsf@localhost> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Ihor Radchenko > Date: Wed, 19 Jul 2023 07:02:21 +0000 > > This is a followup of https://orgmode.org/list/87ilag1pth.fsf@localhost > > We recently ran into some subtleties of point adjustment near invisible > regions with sticky 'invisible property. > > The actual code in `set_point_both' makes sure to move point across > invisible sticky region if point happens to end up right before front > sticky invisible or right after rear sticky invisible region. > > However, 22.6 Adjusting Point After Commands does not mention this > scenario. > > Further, `set_point_both' contains the following comments: > > /* If the preceding character is both intangible and invisible, > and the invisible property is `rear-sticky', perturb it so > that the search starts one character earlier -- this ensures > that point can never move to the end of an invisible/ > intangible/rear-sticky region. */ > charpos = adjust_for_invis_intang (charpos, -1, -1, 1); > <...> > /* If the following character is both intangible and invisible, > and the invisible property is `front-sticky', perturb it so > that the search starts one character later -- this ensures > that point can never move to the beginning of an > invisible/intangible/front-sticky region. */ > charpos = adjust_for_invis_intang (charpos, 0, 1, 1); > > However, 'intanglible text property is, in fact, not necessary to > trigger the adjustment. > > May you (1) document this behaviour in the manual; (2) clarify what's up > with intanglible. I think you confuse two different point-adjustment behaviors. What the ELisp manual describes is the one implemented in adjust_point_for_property and the code which calls it from command_loop_1. set_point_both does a different job for different situations, AFAIU. If you ignore set_point_both, what exactly is wrong about that short section in the manual? Adding Stefan, in case he has comments. From unknown Sun Jun 15 08:58:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#64724: 30.0.50; Inconsistency between manual, comments in the code, and implementation of point adjustment Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 19 Jul 2023 17:32:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64724 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Ihor Radchenko , 64724@debbugs.gnu.org Received: via spool by 64724-submit@debbugs.gnu.org id=B64724.168978791815564 (code B ref 64724); Wed, 19 Jul 2023 17:32:01 +0000 Received: (at 64724) by debbugs.gnu.org; 19 Jul 2023 17:31:58 +0000 Received: from localhost ([127.0.0.1]:57077 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMB1n-00042t-SI for submit@debbugs.gnu.org; Wed, 19 Jul 2023 13:31:58 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:22689) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMB1i-00042c-Mf for 64724@debbugs.gnu.org; Wed, 19 Jul 2023 13:31:54 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 6C2431000C3; Wed, 19 Jul 2023 13:31:45 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 692BB10002F; Wed, 19 Jul 2023 13:31:44 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1689787904; bh=3GTnLLHFvz2XVABmUVLLC0mq9X2bQ1Pd1aqRE2MtpbE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ivL8T7IYEUCDXTwCdEeCWf0pauSJ8dQ/DJ/Y0+V0H/wc+F7v7vCx+pQF4yZFmjGWM FLM90YNExzP6vYjDT8jKcWy5NoQ02Oy4EiliszzO8PFQKOB3bf1U01uwmCq2H8YR73 UeVZ347n8fZBBj0TuK2sv8Apr/lZsTRy4J1DJblTzLR7P6DKPh7DKpQCsK86k96XIH xSczFQH4hzlvMgqIS9NS+nBCLAo9sxqyXzFxF5CNEv/wLYxzyjkLYijLYIrtb2sLnr gkIvmkH0yJBvKahT4UHxBMYxgI1FILHfah6HTFAJwCSd8ZqiuH3xgYeUTwVdGEBgKu ccUrKTed8A5BA== Received: from alfajor (unknown [104.247.226.95]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 278D4120399; Wed, 19 Jul 2023 13:31:44 -0400 (EDT) From: Stefan Monnier In-Reply-To: <83fs5j4zti.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 19 Jul 2023 19:43:21 +0300") Message-ID: References: <87bkg81j0i.fsf@localhost> <83fs5j4zti.fsf@gnu.org> Date: Wed, 19 Jul 2023 13:31:43 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.094 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > I think you confuse two different point-adjustment behaviors. What > the ELisp manual describes is the one implemented in > adjust_point_for_property and the code which calls it from > command_loop_1. set_point_both does a different job for different > situations, AFAIU. Indeed, the `set_point_both` adjustment is an obsolete (mis-)feature that has been deprecated since Emacs-25, when `inhibit-point-motion-hooks`s default has been changed to t (and replaced with `cursor-sensor-mode` and `cursor-intangible-mode`). Stefan From unknown Sun Jun 15 08:58:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#64724: 30.0.50; Inconsistency between manual, comments in the code, and implementation of point adjustment Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Jul 2023 09:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64724 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 64724@debbugs.gnu.org, Stefan Monnier Received: via spool by 64724-submit@debbugs.gnu.org id=B64724.16898467111523 (code B ref 64724); Thu, 20 Jul 2023 09:52:02 +0000 Received: (at 64724) by debbugs.gnu.org; 20 Jul 2023 09:51:51 +0000 Received: from localhost ([127.0.0.1]:57702 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMQK7-0000OU-C9 for submit@debbugs.gnu.org; Thu, 20 Jul 2023 05:51:51 -0400 Received: from mout02.posteo.de ([185.67.36.66]:49209) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMQK4-0000OH-8D for 64724@debbugs.gnu.org; Thu, 20 Jul 2023 05:51:49 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 6E96F240105 for <64724@debbugs.gnu.org>; Thu, 20 Jul 2023 11:51:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1689846702; bh=l7jOkH3F4BGMTV5X+3v7ckXxPfOlmioyqVpmpn+HspQ=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=NgQlZnglY/EcezrEZc5mNFmrCGOGai4EyI5D+6v2JzuvwfN9jTshjceRVjwqz9Vmb mdniD06ItYg5ZvzLvfwRYfYimKNIBuH9QF0SbWcZFTSghBlnG17Edh5kdGRu2m2zX2 HDL2P+Rtp0atvdlzk28bxAWIUz6DzYU/D61VApqke07d2FxsOwnD9lBiZLZRwPG4j9 p/eMxEWWDj4CPfiOnbwRfzbJh49pAj2hVFazLDjzgFcfwZqk0bcfM6d9mf9HHOKnCV UwdxI57MabHkYSbPLtHNmWD6W6sIef+4cqh8+2wx3JwmmQEhD2v7fFWLqDo1fjL3ag 0gDs9cIYHKixA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4R67Hx1xQTz6v01; Thu, 20 Jul 2023 11:51:41 +0200 (CEST) From: Ihor Radchenko In-Reply-To: <83fs5j4zti.fsf@gnu.org> References: <87bkg81j0i.fsf@localhost> <83fs5j4zti.fsf@gnu.org> Date: Thu, 20 Jul 2023 09:51:52 +0000 Message-ID: <878rbarjuv.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> May you (1) document this behaviour in the manual; (2) clarify what's up >> with intanglible. > > I think you confuse two different point-adjustment behaviors. What > the ELisp manual describes is the one implemented in > adjust_point_for_property and the code which calls it from > command_loop_1. set_point_both does a different job for different > situations, AFAIU. > If you ignore set_point_both, what exactly is wrong about that short > section in the manual? Let me describe the full sequence how I arrived to that manual page: 1. We had a situation where `backward-word' moved further than expected: =word M-b =word This was despite "=" not considered to be a word constituent in syntax table. 2. I noticed that this behavior is related to point movement and invisible text and searched manual index for "point", "invisible". The only match was "22.6 Adjusting Point After Commands" I assumed that it is describing all the cases related to interaction between point and invisible text. 3. I've read that section of the manual and did not find anything about point ending up not inside, but at the boundary of invisible text. 4. I reached to sources and tried to track down the cause, eventually arriving to `set_point_both'. So, there is no problem with this section of the manual. The problem is that manual does not describe the behavior with invisible text boundaries I was trying to figure out. (Or does not properly mark the relevant section with index keywords). -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From unknown Sun Jun 15 08:58:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#64724: 30.0.50; Inconsistency between manual, comments in the code, and implementation of point adjustment Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Jul 2023 09:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64724 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: Eli Zaretskii , 64724@debbugs.gnu.org Received: via spool by 64724-submit@debbugs.gnu.org id=B64724.16898470191963 (code B ref 64724); Thu, 20 Jul 2023 09:57:02 +0000 Received: (at 64724) by debbugs.gnu.org; 20 Jul 2023 09:56:59 +0000 Received: from localhost ([127.0.0.1]:57707 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMQP5-0000Vb-6q for submit@debbugs.gnu.org; Thu, 20 Jul 2023 05:56:59 -0400 Received: from mout02.posteo.de ([185.67.36.66]:35791) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMQP3-0000VK-8G for 64724@debbugs.gnu.org; Thu, 20 Jul 2023 05:56:58 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id A797A240101 for <64724@debbugs.gnu.org>; Thu, 20 Jul 2023 11:56:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1689847011; bh=1BsLmcSIXqY+rm9OK/3v+s+6vL4DHXRJnJugaSbcPfM=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=btsAnPrUJWjlEkzHoyv+pW7zG5uB0rXpmhWymnBCsfZE3gPTpzd2RwSRo6wjQk67O m2iPiDeJU9EDN36x0hne82jq3QjNtkWJsEUQNNsbTmFZZL8DKH1kKhZ6KdmYpKy+m+ CEHMLJPznsuP8ACf68tH+iNLoQK3FnCaziPL1pS9McHHnLFB3g1tvDJx6q06ai6BGq uO0+N4v7J2H/ndogn3UkX06SRT4SaKQxe4aoELxoz4RV9MpwIa8yjxdStIxftVJPaz 2mZnEAHgN9mT3LtQ/j2BCCiLmjVkV+MfEvCJzACRG7EdFg3D6Aj4FKVMvEiC4FStkf IwiAjsVs3WhbQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4R67Pv0WWKz6tyR; Thu, 20 Jul 2023 11:56:50 +0200 (CEST) From: Ihor Radchenko In-Reply-To: References: <87bkg81j0i.fsf@localhost> <83fs5j4zti.fsf@gnu.org> Date: Thu, 20 Jul 2023 09:57:02 +0000 Message-ID: <875y6erjm9.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Stefan Monnier writes: > Indeed, the `set_point_both` adjustment is an obsolete (mis-)feature > that has been deprecated since Emacs-25, when > `inhibit-point-motion-hooks`s default has been changed to t (and > replaced with `cursor-sensor-mode` and > `cursor-intangible-mode`). Will it ever be removed though? It appears to affect outline mode a lot. We just recently received a somewhat related report with yet another point adjustment subtlety: * Short heading... * Very very very very long heading... C-p will move after hidden text above: * Short heading... * Very very very very long heading... And I am pretty sure that there are many edge cases like this, which rely on the implementation details with point adjustment. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From unknown Sun Jun 15 08:58:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#64724: 30.0.50; Inconsistency between manual, comments in the code, and implementation of point adjustment Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Jul 2023 10:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64724 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ihor Radchenko Cc: 64724@debbugs.gnu.org, monnier@iro.umontreal.ca Received: via spool by 64724-submit@debbugs.gnu.org id=B64724.16898488055673 (code B ref 64724); Thu, 20 Jul 2023 10:27:02 +0000 Received: (at 64724) by debbugs.gnu.org; 20 Jul 2023 10:26:45 +0000 Received: from localhost ([127.0.0.1]:57757 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMQrt-0001TQ-3X for submit@debbugs.gnu.org; Thu, 20 Jul 2023 06:26:45 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45668) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMQrq-0001TC-U0 for 64724@debbugs.gnu.org; Thu, 20 Jul 2023 06:26:43 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qMQrl-0007y0-CN; Thu, 20 Jul 2023 06:26:37 -0400 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=KNgkaFcq9IklYLbV6g970xzPehhOzEZtATdRKB6qz5s=; b=JjJPvEth7IIs zPjWzZcoS6p7IWoDrpc6Qn10EBoVQZIlGvRcHgk6CWpljSE0oP7Og4psi4Ssj8GXxpO2BecX62CmV dWCfx8sj/R1LHliR4eKaVLWeLLrLTFX3KoQGzH5qFsM80qTd8eYYzhFa9aFtThSXmRhC0vFooc6zq W4DoQu9l1W87UXAsAGuRySu9uet99j0UL5Wji66u0Tw2/xUIWgpVVl/NdUvNbX1INAd5tu9yCDOgX DTjiNSCxbMUAonJ9mAOz0SlMK83jKIOUoN4V37/hMyGtYc6+XWbPnKVIKRqCWPOBRsJ2bPw8s5l6z lNv8/98+7/fYi6sIXKcLAQ==; Received: from [87.69.77.57] (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 1qMQrk-0002QJ-S9; Thu, 20 Jul 2023 06:26:37 -0400 Date: Thu, 20 Jul 2023 13:27:10 +0300 Message-Id: <83pm4m3mkh.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <878rbarjuv.fsf@localhost> (message from Ihor Radchenko on Thu, 20 Jul 2023 09:51:52 +0000) References: <87bkg81j0i.fsf@localhost> <83fs5j4zti.fsf@gnu.org> <878rbarjuv.fsf@localhost> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Ihor Radchenko > Cc: Stefan Monnier , 64724@debbugs.gnu.org > Date: Thu, 20 Jul 2023 09:51:52 +0000 > > So, there is no problem with this section of the manual. The problem is > that manual does not describe the behavior with invisible text > boundaries I was trying to figure out. Which aspects of the behavior you describe are not mentioned in the manual. It does refer to invisible text. From unknown Sun Jun 15 08:58:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#64724: 30.0.50; Inconsistency between manual, comments in the code, and implementation of point adjustment Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 21 Jul 2023 02:41:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64724 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ihor Radchenko Cc: Eli Zaretskii , 64724@debbugs.gnu.org Received: via spool by 64724-submit@debbugs.gnu.org id=B64724.168990720218678 (code B ref 64724); Fri, 21 Jul 2023 02:41:01 +0000 Received: (at 64724) by debbugs.gnu.org; 21 Jul 2023 02:40:02 +0000 Received: from localhost ([127.0.0.1]:60266 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMg3m-0004r2-3X for submit@debbugs.gnu.org; Thu, 20 Jul 2023 22:40:02 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:53816) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMg3j-0004qd-Ly for 64724@debbugs.gnu.org; Thu, 20 Jul 2023 22:40:00 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 2DE091000C4; Thu, 20 Jul 2023 22:39:54 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 25E4910001C; Thu, 20 Jul 2023 22:39:53 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1689907193; bh=EuRA8CGAjwxYlUy2z4c2UNQezD4JPWzZ0LGNELts/1w=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ksBIJWvOAMuZQuK5uyVqjt/rUUEoiQGjTCLW1fcqs/sCcxEn9N36EkIsk4NgKKErO AXN2gieU/1JAtjrTL/IgLx+T/m9Pu+rRXoDkq7qGesKA11IMOS5jFKj6K5WjqMsSIn qGHtdr3a3MfG2CYGHItgH4Bkk9fnHUBq38uPCl2nGnDmXk9dU0ETsxHUSq42VDIXl0 FCXUHxYHXTGO9w/Xpaz6BTMdpyrLEXn2VaeElCttEXRGnaeyBhA6IBoNQf3s9US487 8UZwe1B0t+e8dWWepSuaeXIZnRpFTn4ehTmNWw1AqJET+WGtV0OSKad5/x8RLPZYap jePE/HK6AonOg== Received: from pastel (unknown [104.247.231.138]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E61C512005A; Thu, 20 Jul 2023 22:39:52 -0400 (EDT) From: Stefan Monnier In-Reply-To: <878rbarjuv.fsf@localhost> (Ihor Radchenko's message of "Thu, 20 Jul 2023 09:51:52 +0000") Message-ID: References: <87bkg81j0i.fsf@localhost> <83fs5j4zti.fsf@gnu.org> <878rbarjuv.fsf@localhost> Date: Thu, 20 Jul 2023 22:39:52 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.093 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Let me describe the full sequence how I arrived to that manual page: > > 1. We had a situation where `backward-word' moved further than expected: > > =word > M-b > =word > > This was despite "=" not considered to be a word constituent in > syntax table. > > 2. I noticed that this behavior is related to point movement and > invisible text and searched manual index for "point", "invisible". > The only match was "22.6 Adjusting Point After Commands" > I assumed that it is describing all the cases related to interaction > between point and invisible text. > > 3. I've read that section of the manual and did not find anything about > point ending up not inside, but at the boundary of invisible text. The boundary is usually considered as "inside" for this specific case. More specifically, in your above example, at the end of the command point ends up being *displayed* at a position that could correspond to various buffer positions, and the 22.6 point-adjustment will thus try and choose which of those buffer positions to use (based on the stickiness, as well as the direction of movement). > 4. I reached to sources and tried to track down the cause, eventually > arriving to `set_point_both'. Hmm... I'd be very surprised if `set_point_both` is the cause: `inhibit-point-motion-hooks` should be non-nil, so that code will simply be skipped. If `inhibit-point-motion-hooks` is nil, please send me the recipe so I can try and change the caller that set this var. Stefan From unknown Sun Jun 15 08:58:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#64724: 30.0.50; Inconsistency between manual, comments in the code, and implementation of point adjustment Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 21 Jul 2023 02:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64724 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ihor Radchenko Cc: Eli Zaretskii , 64724@debbugs.gnu.org Received: via spool by 64724-submit@debbugs.gnu.org id=B64724.168990764319486 (code B ref 64724); Fri, 21 Jul 2023 02:48:02 +0000 Received: (at 64724) by debbugs.gnu.org; 21 Jul 2023 02:47:23 +0000 Received: from localhost ([127.0.0.1]:60286 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMgAt-00054D-Er for submit@debbugs.gnu.org; Thu, 20 Jul 2023 22:47:23 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:18305) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMgAr-00053z-IU for 64724@debbugs.gnu.org; Thu, 20 Jul 2023 22:47:22 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 48489801B3; Thu, 20 Jul 2023 22:47:16 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id DD90880058; Thu, 20 Jul 2023 22:47:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1689907630; bh=54A4FciDuMxTkrd21O8OvXrvTsr2rApTGM841ErYlLE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=KrkPhYWW4XC3hlt03ajt6HiHm5hLWvFjc3vUV5UlkqWBz0zHvde9cGhLCPeiU8k0I pyjJWOpqqmYMN6P4Yr7wHH9JrXAiDCAeX8W/f8gPZSmtPNoBdPEACGLQxg6MRkY87M sdjE62PouP31RJrmBEdDFRrRJf/5cf4j8mCTwv7LI8OQvNuruKqLu3ahnQpZ9271Yh ItSfuoESB03sNzz/ZVcLhagMhQjo0xzG7/Mu98fzu/7utXC4cHLF0Q+5OX+hPvyeUi 1xC79wjYtk/a/8RPKaftDZAUFenC4/5HF3NgbRmvyvpeaHUfLh2T4vEdwyQW28UXXv OLxxorIwzZRmw== Received: from pastel (unknown [104.247.231.138]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B26C612039E; Thu, 20 Jul 2023 22:47:10 -0400 (EDT) From: Stefan Monnier In-Reply-To: <875y6erjm9.fsf@localhost> (Ihor Radchenko's message of "Thu, 20 Jul 2023 09:57:02 +0000") Message-ID: References: <87bkg81j0i.fsf@localhost> <83fs5j4zti.fsf@gnu.org> <875y6erjm9.fsf@localhost> Date: Thu, 20 Jul 2023 22:47:10 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.056 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Ihor Radchenko [2023-07-20 09:57:02] wrote: > Stefan Monnier writes: >> Indeed, the `set_point_both` adjustment is an obsolete (mis-)feature >> that has been deprecated since Emacs-25, when >> `inhibit-point-motion-hooks`s default has been changed to t (and >> replaced with `cursor-sensor-mode` and >> `cursor-intangible-mode`). > > Will it ever be removed though? That's the plan, yes. In Emacs-29, I removed all the places where we defensively let-bound it to non-nil, in preparation for the actual removal. > It appears to affect outline mode a lot. > > We just recently received a somewhat related report with yet another > point adjustment subtlety: > > * Short heading... > * Very very very very long heading... > > C-p will move after hidden text above: > > * Short heading... > * Very very very very long heading... I suspect this has nothing to do with `inhibit-point-motion-hooks` nor `set-point-both` but with the post-command point-adjustment, instead. > And I am pretty sure that there are many edge cases like this, which > rely on the implementation details with point adjustment. point-adjustment cannot get all cases right, because (like in the above example), the "right" thing to do depends on the specific semantics of the last command (e.g. was the last command supposed to move by one logical line or one screen line?). IIRC, `C-p` has ad-hoc code to try and handle cases like the above, but apparently it doesn't handle this specific case. Stefan From unknown Sun Jun 15 08:58:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#64724: 30.0.50; Inconsistency between manual, comments in the code, and implementation of point adjustment Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 21 Jul 2023 07:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64724 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 64724@debbugs.gnu.org, monnier@iro.umontreal.ca Received: via spool by 64724-submit@debbugs.gnu.org id=B64724.168992585522961 (code B ref 64724); Fri, 21 Jul 2023 07:51:01 +0000 Received: (at 64724) by debbugs.gnu.org; 21 Jul 2023 07:50:55 +0000 Received: from localhost ([127.0.0.1]:60479 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMkuc-0005yH-Od for submit@debbugs.gnu.org; Fri, 21 Jul 2023 03:50:55 -0400 Received: from mout01.posteo.de ([185.67.36.65]:34537) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMkuY-0005xn-3L for 64724@debbugs.gnu.org; Fri, 21 Jul 2023 03:50:52 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 854E0240029 for <64724@debbugs.gnu.org>; Fri, 21 Jul 2023 09:50:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1689925844; bh=0uM5gexrbEHyn7CR9MQzADOBO54N7t+6ystuLuDCxWQ=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:From; b=F0KP4rfuVQcXPDEV1m8sCA1Ga/YXG4N3sLo7BgaJ4TLD1aBEN0dSllq2nMCmJ2iu2 N5g3VXf8DcRm/ZKkTdSf4Q7F2W8z7jVZMzWy4LsexSHfBhiJdVHZuseQ4SmaVWsVJv P8c1QEr+eJTqwOU2PY/oWNPMs+cXYd6Dg+KbgmkMj7+6sIfCWEShfaFl4zsvQsJxpP 0t1EO88CobRaUEvtmi96dj2739J2dczNeMup7S4kvSJSZBKNObBi0oeOJ7/fbvqnoY PyWa2wh5JDj54WVaAbvsEisx//l1F1i4HFftLQbAsuaCDVSNWhOD15+7oF0XV/edHU Zx0FLO9iV8C8g== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4R6hYv3wlqz6tvm; Fri, 21 Jul 2023 09:50:43 +0200 (CEST) From: Ihor Radchenko In-Reply-To: <83pm4m3mkh.fsf@gnu.org> References: <87bkg81j0i.fsf@localhost> <83fs5j4zti.fsf@gnu.org> <878rbarjuv.fsf@localhost> <83pm4m3mkh.fsf@gnu.org> Date: Fri, 21 Jul 2023 07:50:55 +0000 Message-ID: <87tttx7leo.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> So, there is no problem with this section of the manual. The problem is >> that manual does not describe the behavior with invisible text >> boundaries I was trying to figure out. > > Which aspects of the behavior you describe are not mentioned in the > manual. It does refer to invisible text. It talks about "in the middle of a sequence .. that ... is invisible" Emacs cannot display the cursor when point is in the middle of a sequence of text that has the =E2=80=98display=E2=80=99 or =E2=80=98com= position=E2=80=99 property, or is invisible. Therefore, after a command finishes and returns to the command loop, if point is within such a sequence, the command loop normally moves point to the edge of the sequence, making this sequence effectively intangible. The situation I encountered is when point ends up not in the middle, but already on the edge. So, Emacs moving point to _other_ edge was surprising. --=20 Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From unknown Sun Jun 15 08:58:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#64724: 30.0.50; Inconsistency between manual, comments in the code, and implementation of point adjustment Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 21 Jul 2023 09:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64724 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: Eli Zaretskii , 64724@debbugs.gnu.org Received: via spool by 64724-submit@debbugs.gnu.org id=B64724.168993070931301 (code B ref 64724); Fri, 21 Jul 2023 09:12:02 +0000 Received: (at 64724) by debbugs.gnu.org; 21 Jul 2023 09:11:49 +0000 Received: from localhost ([127.0.0.1]:60550 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMmAu-00088n-LM for submit@debbugs.gnu.org; Fri, 21 Jul 2023 05:11:48 -0400 Received: from mout02.posteo.de ([185.67.36.66]:37661) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMmAq-00088W-Bc for 64724@debbugs.gnu.org; Fri, 21 Jul 2023 05:11:47 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 32F53240101 for <64724@debbugs.gnu.org>; Fri, 21 Jul 2023 11:11:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1689930698; bh=9f2PEG8Nkj1sJ7tODqqOBvBd6LTmv7dEu/cOeZNMXNI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=sDI/rqP/H+8tPR7uFtbo0TPC05ZHqv7a0tTZyY/pJMpjBXD1Xcdgwyqeb4Jxtt25g Q+X2bjKvUV6+BHUDgi4FczZ7UDBDQNw/XHvj3cmNjx5s1ra1v7Fh75OvmcHPvxg9tO iefCLUcxjJc7UI5mbH/hcmya5lODQ4hO1LuJ+E27+Vo4tfou5qr1Nhjy8TS0RF0oNl Z1J+MNKtsGUmZ+bJ0jsj1o5BDv3DnOPRCdBeO2xm4Q1nFNrVQC+X1SYZuu5N1L6jjT dQfX2kH6uN6tVp98RPEBTmaQAsNdnfNE9Omlia4na1+Mamf9hA9Fig1jf9FBlk/qmf D3ZxEc8hiV5Qw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4R6kMF0bw2z6twb; Fri, 21 Jul 2023 11:11:36 +0200 (CEST) From: Ihor Radchenko In-Reply-To: References: <87bkg81j0i.fsf@localhost> <83fs5j4zti.fsf@gnu.org> <878rbarjuv.fsf@localhost> Date: Fri, 21 Jul 2023 09:11:49 +0000 Message-ID: <87zg3p633e.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Stefan Monnier writes: >> 3. I've read that section of the manual and did not find anything about >> point ending up not inside, but at the boundary of invisible text. > > The boundary is usually considered as "inside" for this specific case. I did not expect this. It should be clarified, if true. Because the same paragraph says that point will be moved to the boundary. Combined with motion to _another_ boundary, I see not how I can understand what is happening from the info node. >> 4. I reached to sources and tried to track down the cause, eventually >> arriving to `set_point_both'. > > Hmm... I'd be very surprised if `set_point_both` is the cause: > `inhibit-point-motion-hooks` should be non-nil, so that code will simply > be skipped. > > If `inhibit-point-motion-hooks` is nil, please send me the recipe so > I can try and change the caller that set this var. You are right. I now tried =word= M-: (progn (backward-word) (message "%s" (point))) The message displays point at "w". Yet, when I follow this up with M-: (point), the output is at "=". The actual cause if probably `adjust_point_for_property'. Although I do not fully understand how it works. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From unknown Sun Jun 15 08:58:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#64724: 30.0.50; Inconsistency between manual, comments in the code, and implementation of point adjustment Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 21 Jul 2023 10:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64724 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ihor Radchenko Cc: 64724@debbugs.gnu.org, monnier@iro.umontreal.ca Received: via spool by 64724-submit@debbugs.gnu.org id=B64724.16899366449947 (code B ref 64724); Fri, 21 Jul 2023 10:51:01 +0000 Received: (at 64724) by debbugs.gnu.org; 21 Jul 2023 10:50:44 +0000 Received: from localhost ([127.0.0.1]:60657 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMnie-0002aN-BK for submit@debbugs.gnu.org; Fri, 21 Jul 2023 06:50:44 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53618) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMnic-0002aB-GT for 64724@debbugs.gnu.org; Fri, 21 Jul 2023 06:50:43 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qMniV-0004bf-18; Fri, 21 Jul 2023 06:50:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=70aSXxztRTgoEHgqKCfjtBEUdICB26vldJdRaaxLmmE=; b=RyR5UF+5+8N3nyjfs2Ef Ah8Mv7ZNM9TDilrUJEQoFwNuyR2KPMjGg+f7wVph8dxcMFa/5jEb8T0TGF8c5oio3OBidexf8HBzS /acnpnZSM8aVKfTERYa06jN4+/7Z2fdBkTBmlN2HJ9ayG4QNdZ8WCvv6bcGkOCBg48UwQu5QFdwJz 6B4cg9KKqHDPwWqsd/WsL1JrlWLXFiKFXR11ZCu8ABu6ctasY1igpvpoVs08pphB6jz1aW5Hu3U0B nHa43WiG97epzFwDEAafesrIjOoCV1h7AbJTD3I6abTZmQ3/VfhRrMpYNruCn8gIVUiHuIslNXZ93 FDOL0jVm46Y6gg==; Received: from [87.69.77.57] (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 1qMniO-0000ov-4O; Fri, 21 Jul 2023 06:50:34 -0400 Date: Fri, 21 Jul 2023 13:51:04 +0300 Message-Id: <83cz0l1qsn.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87tttx7leo.fsf@localhost> (message from Ihor Radchenko on Fri, 21 Jul 2023 07:50:55 +0000) References: <87bkg81j0i.fsf@localhost> <83fs5j4zti.fsf@gnu.org> <878rbarjuv.fsf@localhost> <83pm4m3mkh.fsf@gnu.org> <87tttx7leo.fsf@localhost> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Ihor Radchenko > Cc: monnier@iro.umontreal.ca, 64724@debbugs.gnu.org > Date: Fri, 21 Jul 2023 07:50:55 +0000 > > Eli Zaretskii writes: > > >> So, there is no problem with this section of the manual. The problem is > >> that manual does not describe the behavior with invisible text > >> boundaries I was trying to figure out. > > > > Which aspects of the behavior you describe are not mentioned in the > > manual. It does refer to invisible text. > > It talks about "in the middle of a sequence .. that ... is invisible" > > Emacs cannot display the cursor when point is in the middle of a > sequence of text that has the ‘display’ or ‘composition’ property, or is > invisible. Therefore, after a command finishes and returns to the > command loop, if point is within such a sequence, the command loop > normally moves point to the edge of the sequence, making this sequence > effectively intangible. > > The situation I encountered is when point ends up not in the middle, but > already on the edge. So, Emacs moving point to _other_ edge was > surprising. That's because where to move point in these situations depends on where it was before. We could describe these details of the heuristics we use, but I very much doubt it will be useful in practice. And the heuristics could change in the future, which makes this a maintenance problem. So I tend to think this bug should be closed with no further action. The main purpose of that node is to explain how to disable this point adjustment, not describe in detail what it does and how. From unknown Sun Jun 15 08:58:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#64724: 30.0.50; Inconsistency between manual, comments in the code, and implementation of point adjustment Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 21 Jul 2023 12:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64724 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 64724@debbugs.gnu.org, monnier@iro.umontreal.ca Received: via spool by 64724-submit@debbugs.gnu.org id=B64724.168994169428478 (code B ref 64724); Fri, 21 Jul 2023 12:15:02 +0000 Received: (at 64724) by debbugs.gnu.org; 21 Jul 2023 12:14:54 +0000 Received: from localhost ([127.0.0.1]:60736 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMp26-0007PF-Cj for submit@debbugs.gnu.org; Fri, 21 Jul 2023 08:14:54 -0400 Received: from mout01.posteo.de ([185.67.36.65]:40357) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMp22-0007Oy-Vs for 64724@debbugs.gnu.org; Fri, 21 Jul 2023 08:14:52 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id D63BC240027 for <64724@debbugs.gnu.org>; Fri, 21 Jul 2023 14:14:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1689941684; bh=JGlaPk1hmA0OiwKCFPXpW0eSNulNrYc1xtB7SnNkdtk=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=F8t94Q0qO3fIDZxZ5AueS5TUVh0W7CU1PJH6JHiXemZpc84HiQaPV/OAwRJOMceOb 5MHUn4ycUCvcscKS1wC0mZ6k7TNUGVsZgh3tIXsqWidOHsQhAgWC5RH+sx1Sru5tRT Nwga8nryApV11r/q8t9r7/jXG3ptCLoV+n4H1Zybp/1Hj1yfaBlE3UIKg8pu4SmJ5G 8es4GKs8EOYabUy+oqlCK151q0rpdBBHUF7D4PRqnHTSEtYAlwa7Pqj4wD8MN6Eyu+ MFwtrgsB7Qm1RmxouGEuxtUFVQEnjh/zQlzhIZ5/qCec5V/jqUHw84F02g8z/ZqXuC EXjpAjMkL86OA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4R6pQW5jLvz9rxK; Fri, 21 Jul 2023 14:14:43 +0200 (CEST) From: Ihor Radchenko In-Reply-To: <83cz0l1qsn.fsf@gnu.org> References: <87bkg81j0i.fsf@localhost> <83fs5j4zti.fsf@gnu.org> <878rbarjuv.fsf@localhost> <83pm4m3mkh.fsf@gnu.org> <87tttx7leo.fsf@localhost> <83cz0l1qsn.fsf@gnu.org> Date: Fri, 21 Jul 2023 12:14:55 +0000 Message-ID: <87iladmpfk.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> The situation I encountered is when point ends up not in the middle, but >> already on the edge. So, Emacs moving point to _other_ edge was >> surprising. > > That's because where to move point in these situations depends on > where it was before. We could describe these details of the > heuristics we use, but I very much doubt it will be useful in > practice. And the heuristics could change in the future, which makes > this a maintenance problem. I think you misunderstood. I know that the logic how Emacs chooses which boundary to move to is not documented. However, my problem is not with this logic. My problem is that info page says that point adjustment happens when point is _inside_ invisible region. However, in my situation the point is already at the boundary (that is: _not inside_). > So I tend to think this bug should be closed with no further action. > The main purpose of that node is to explain how to disable this point > adjustment, not describe in detail what it does and how. Please remember that info page was just one of the points I listed in the initial report. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From unknown Sun Jun 15 08:58:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#64724: 30.0.50; Inconsistency between manual, comments in the code, and implementation of point adjustment Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 21 Jul 2023 12:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64724 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ihor Radchenko Cc: 64724@debbugs.gnu.org, monnier@iro.umontreal.ca Received: via spool by 64724-submit@debbugs.gnu.org id=B64724.168994342931629 (code B ref 64724); Fri, 21 Jul 2023 12:44:02 +0000 Received: (at 64724) by debbugs.gnu.org; 21 Jul 2023 12:43:49 +0000 Received: from localhost ([127.0.0.1]:60842 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMpU5-0008E3-CF for submit@debbugs.gnu.org; Fri, 21 Jul 2023 08:43:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47080) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMpU1-0008Dq-Sh for 64724@debbugs.gnu.org; Fri, 21 Jul 2023 08:43:47 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qMpTv-0004Wz-Vu; Fri, 21 Jul 2023 08:43:40 -0400 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=8fgWJio8A8/b5/+Ww0uDt5LlvkkN+cn5iCRhAzPdUc4=; b=ftqoPlSVjC8u c9xh0mgrRH9yrPt2wh9GXPgRG13a+0x+JhTDGpJYIsZvF4Dbb/P8n+cz4cxupHcQPARoD0R1Q63s+ rcdKmYTFdS74jfPYLiDrZ0Qxzbje1JqCSTVlOr60OspCewAds50Mc4qO06gBcwbK88wx9RQCiKxuk y1D8Y8B25gAV9xnMdY7kPUuZ5mefzqwzNTdnUkFvPdXuUZF9gHRMZ3vSRXwGA9gOtL6duKBmP0yvf i6ZHkHvFlJrpBvF5/ryT+LnVe4NyY7+8/JRnCUtON1SM3M2Nd/mhQy56gOFfmSzUI928QCMWzCGYe /FYvZT45giQG9q2APdByqQ==; Received: from [87.69.77.57] (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 1qMpTu-0005rg-Gt; Fri, 21 Jul 2023 08:43:39 -0400 Date: Fri, 21 Jul 2023 15:44:13 +0300 Message-Id: <83wmytzb6q.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87iladmpfk.fsf@localhost> (message from Ihor Radchenko on Fri, 21 Jul 2023 12:14:55 +0000) References: <87bkg81j0i.fsf@localhost> <83fs5j4zti.fsf@gnu.org> <878rbarjuv.fsf@localhost> <83pm4m3mkh.fsf@gnu.org> <87tttx7leo.fsf@localhost> <83cz0l1qsn.fsf@gnu.org> <87iladmpfk.fsf@localhost> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Ihor Radchenko > Cc: monnier@iro.umontreal.ca, 64724@debbugs.gnu.org > Date: Fri, 21 Jul 2023 12:14:55 +0000 > > Eli Zaretskii writes: > > > That's because where to move point in these situations depends on > > where it was before. We could describe these details of the > > heuristics we use, but I very much doubt it will be useful in > > practice. And the heuristics could change in the future, which makes > > this a maintenance problem. > > I think you misunderstood. > I know that the logic how Emacs chooses which boundary to move to is not > documented. > > However, my problem is not with this logic. My problem is that info page > says that point adjustment happens when point is _inside_ invisible > region. However, in my situation the point is already at the boundary > (that is: _not inside_). Stefan explained that aspect, so I didn't see the point in reiterating it. > > So I tend to think this bug should be closed with no further action. > > The main purpose of that node is to explain how to disable this point > > adjustment, not describe in detail what it does and how. > > Please remember that info page was just one of the points I listed in > the initial report. I must have missed them (even though I've skimmed the discussion again now), so please point them out again. (And please don't use the incorrect term "Info page". Unlike "man pages", the Info documentation doesn't come as a collection of "pages" it comes in the form of complete manuals.) From unknown Sun Jun 15 08:58:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#64724: 30.0.50; Inconsistency between manual, comments in the code, and implementation of point adjustment Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 21 Jul 2023 12:57:00 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64724 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 64724@debbugs.gnu.org, monnier@iro.umontreal.ca Received: via spool by 64724-submit@debbugs.gnu.org id=B64724.1689944178886 (code B ref 64724); Fri, 21 Jul 2023 12:57:00 +0000 Received: (at 64724) by debbugs.gnu.org; 21 Jul 2023 12:56:18 +0000 Received: from localhost ([127.0.0.1]:60866 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMpg9-0000ED-Cz for submit@debbugs.gnu.org; Fri, 21 Jul 2023 08:56:17 -0400 Received: from mout01.posteo.de ([185.67.36.65]:43387) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMpg6-0000Dq-5j for 64724@debbugs.gnu.org; Fri, 21 Jul 2023 08:56:16 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 826AB240029 for <64724@debbugs.gnu.org>; Fri, 21 Jul 2023 14:56:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1689944168; bh=Ra07zXCMdD8rzAqv5YFlp4vwJ8FCbrurBLzmnYqqUl0=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=oRBuBAydu1IlDPuMozksTngdGolXOgm8A16cOarxG/fAUgSQgrhJDgYJ45nUx1XSQ 22RrWyh1GH4K3qypEfBKCaxM/N0Uu0ug96ELAv812x/qeja86lEc3wgHX36s6lBtxs Ia9MXQJUajjXqlWETHIeHz/qeuh6RHxjijn9cUnVqKAX+v7nWahMbWBDMP7XNlNIPV FkdfMHGdaDE/PWcHSJ3SuNesR+gUP+sfMIf2gxXo7pyhqw9gjdQFAUFJS4dEs9tZ9R 8aLjxvxfo7YBePda+FDr4bzeA1pAXO/F4Qg1Pu8qdougnuXYa7NJ3FRlKIurmNEkye Q1iO42/1bQvWA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4R6qLH2cB5z6txv; Fri, 21 Jul 2023 14:56:07 +0200 (CEST) From: Ihor Radchenko In-Reply-To: <83wmytzb6q.fsf@gnu.org> References: <87bkg81j0i.fsf@localhost> <83fs5j4zti.fsf@gnu.org> <878rbarjuv.fsf@localhost> <83pm4m3mkh.fsf@gnu.org> <87tttx7leo.fsf@localhost> <83cz0l1qsn.fsf@gnu.org> <87iladmpfk.fsf@localhost> <83wmytzb6q.fsf@gnu.org> Date: Fri, 21 Jul 2023 12:56:19 +0000 Message-ID: <871qh1mnik.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> Please remember that info page was just one of the points I listed in >> the initial report. > > I must have missed them (even though I've skimmed the discussion again > now), so please point them out again. Further, `set_point_both' contains the following comments: /* If the preceding character is both intangible and invisible, and the invisible property is `rear-sticky', perturb it so that the search starts one character earlier -- this ensures that point can never move to the end of an invisible/ intangible/rear-sticky region. */ charpos = adjust_for_invis_intang (charpos, -1, -1, 1); <...> /* If the following character is both intangible and invisible, and the invisible property is `front-sticky', perturb it so that the search starts one character later -- this ensures that point can never move to the beginning of an invisible/intangible/front-sticky region. */ charpos = adjust_for_invis_intang (charpos, 0, 1, 1); However, 'intanglible text property is, in fact, not necessary to trigger the adjustment. > (And please don't use the incorrect term "Info page". Unlike "man > pages", the Info documentation doesn't come as a collection of "pages" > it comes in the form of complete manuals.) I meant info node. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From unknown Sun Jun 15 08:58:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#64724: 30.0.50; Inconsistency between manual, comments in the code, and implementation of point adjustment Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 21 Jul 2023 13:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64724 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ihor Radchenko Cc: 64724@debbugs.gnu.org, monnier@iro.umontreal.ca Received: via spool by 64724-submit@debbugs.gnu.org id=B64724.16899448092847 (code B ref 64724); Fri, 21 Jul 2023 13:07:02 +0000 Received: (at 64724) by debbugs.gnu.org; 21 Jul 2023 13:06:49 +0000 Received: from localhost ([127.0.0.1]:60903 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMpqL-0000jp-29 for submit@debbugs.gnu.org; Fri, 21 Jul 2023 09:06:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54922) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMpqH-0000jR-QR for 64724@debbugs.gnu.org; Fri, 21 Jul 2023 09:06:47 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qMpqC-0001uU-IM; Fri, 21 Jul 2023 09:06:40 -0400 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=65ja+3WkNieaF7KjO4BKxN/N1Xb7XF1Wu1NSW+ixh2o=; b=UxB4U1EdP7Bw yWem41HFocoAVnyRAfWoGjhnmmWHWKNxzVKxDC5NxRacDdhfIshAxuI3VBkp6qf7oenuHpsRzi7nO aL9WSN8B2zDSSKWiw5bH96YR5oX4lT8X1M7DJI9kMWeOrvfAuc1n6+qDySe/p7WYvYhSuWTZ/HcWt +qmsknzGgNQ6STqt2OijboNifZkag7vRNEuuzug5yRLid23bRASScDwHQ5WTIlFyECCjth1DpOujz pKslF+kS/3rd9pZeXGcuWZ4hP2F1fytRD+IwXHC2OYKGPcPLU/dLlQyIK0Mo7DpbHEELJLqD2upAB 0oleYv3/Y4NIkv565AS6bA==; Received: from [87.69.77.57] (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 1qMpqC-0004a2-1t; Fri, 21 Jul 2023 09:06:40 -0400 Date: Fri, 21 Jul 2023 16:07:16 +0300 Message-Id: <83fs5hbegr.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <871qh1mnik.fsf@localhost> (message from Ihor Radchenko on Fri, 21 Jul 2023 12:56:19 +0000) References: <87bkg81j0i.fsf@localhost> <83fs5j4zti.fsf@gnu.org> <878rbarjuv.fsf@localhost> <83pm4m3mkh.fsf@gnu.org> <87tttx7leo.fsf@localhost> <83cz0l1qsn.fsf@gnu.org> <87iladmpfk.fsf@localhost> <83wmytzb6q.fsf@gnu.org> <871qh1mnik.fsf@localhost> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Ihor Radchenko > Cc: monnier@iro.umontreal.ca, 64724@debbugs.gnu.org > Date: Fri, 21 Jul 2023 12:56:19 +0000 > > Eli Zaretskii writes: > > >> Please remember that info page was just one of the points I listed in > >> the initial report. > > > > I must have missed them (even though I've skimmed the discussion again > > now), so please point them out again. > > Further, `set_point_both' contains the following comments: > > /* If the preceding character is both intangible and invisible, > and the invisible property is `rear-sticky', perturb it so > that the search starts one character earlier -- this ensures > that point can never move to the end of an invisible/ > intangible/rear-sticky region. */ > charpos = adjust_for_invis_intang (charpos, -1, -1, 1); > <...> > /* If the following character is both intangible and invisible, > and the invisible property is `front-sticky', perturb it so > that the search starts one character later -- this ensures > that point can never move to the beginning of an > invisible/intangible/front-sticky region. */ > charpos = adjust_for_invis_intang (charpos, 0, 1, 1); > > However, 'intanglible text property is, in fact, not necessary to > trigger the adjustment. Didn't we establish that set_point_both is not relevant to the behavior you see, and in fact is a deprecated feature on its way out? From unknown Sun Jun 15 08:58:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#64724: 30.0.50; Inconsistency between manual, comments in the code, and implementation of point adjustment Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 21 Jul 2023 13:19:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64724 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 64724@debbugs.gnu.org, monnier@iro.umontreal.ca Received: via spool by 64724-submit@debbugs.gnu.org id=B64724.16899455114573 (code B ref 64724); Fri, 21 Jul 2023 13:19:01 +0000 Received: (at 64724) by debbugs.gnu.org; 21 Jul 2023 13:18:31 +0000 Received: from localhost ([127.0.0.1]:60915 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMq1f-0001Be-4j for submit@debbugs.gnu.org; Fri, 21 Jul 2023 09:18:31 -0400 Received: from mout02.posteo.de ([185.67.36.66]:40501) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMq1c-0001BN-B8 for 64724@debbugs.gnu.org; Fri, 21 Jul 2023 09:18:29 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id C8659240101 for <64724@debbugs.gnu.org>; Fri, 21 Jul 2023 15:18:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1689945502; bh=aloaz1rgJbfCPgRuOrh0lGEWLIpnBeIFj1+7hLePyJE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=knhvNgsf6F8fzXMKrzfMGHUaWWldREhumtXA2KQUj7/YTIBL0uj7jdFZCwl61tcck SgMQGKOXFGUzEFjM9PYOWeB1S3EhluHwEUTr5HtTNQSKcDvl0RDyDX44ew74XviAAs TaH1qa4gI+prTXj7YxvgITeFe99gLx90n5P9J1AiQqEp3C2c+NPqXSk/k7k+03chP1 ULrQPNWsxXXLaCze0neRuW/gjHOApYGMhcKl4emQlDOBzaYGklMIHp5qOSS863+IwS qYR3lgZM3PReLYN7vopS7HHtrPwhTg6F1TRjl2nUfTwc57IF/BDNa9raq50BctoUJ0 8ve3tHTPvFpLA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4R6qqx557bz9rxb; Fri, 21 Jul 2023 15:18:21 +0200 (CEST) From: Ihor Radchenko In-Reply-To: <83fs5hbegr.fsf@gnu.org> References: <87bkg81j0i.fsf@localhost> <83fs5j4zti.fsf@gnu.org> <878rbarjuv.fsf@localhost> <83pm4m3mkh.fsf@gnu.org> <87tttx7leo.fsf@localhost> <83cz0l1qsn.fsf@gnu.org> <87iladmpfk.fsf@localhost> <83wmytzb6q.fsf@gnu.org> <871qh1mnik.fsf@localhost> <83fs5hbegr.fsf@gnu.org> Date: Fri, 21 Jul 2023 13:18:33 +0000 Message-ID: <87sf9hl7x2.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> Further, `set_point_both' contains the following comments: >> ... > > Didn't we establish that set_point_both is not relevant to the > behavior you see, and in fact is a deprecated feature on its way out? True. The comments are still confusing though. Of course, if that code is going to be removed soon, there is no point fixing the comments. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From unknown Sun Jun 15 08:58:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#64724: 30.0.50; Inconsistency between manual, comments in the code, and implementation of point adjustment Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 21 Jul 2023 14:59:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64724 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ihor Radchenko Cc: Eli Zaretskii , 64724@debbugs.gnu.org Received: via spool by 64724-submit@debbugs.gnu.org id=B64724.168995150416653 (code B ref 64724); Fri, 21 Jul 2023 14:59:01 +0000 Received: (at 64724) by debbugs.gnu.org; 21 Jul 2023 14:58:24 +0000 Received: from localhost ([127.0.0.1]:34478 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMraJ-0004KX-PZ for submit@debbugs.gnu.org; Fri, 21 Jul 2023 10:58:24 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:36384) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMraE-0004KI-Ol for 64724@debbugs.gnu.org; Fri, 21 Jul 2023 10:58:22 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 73EF910006C; Fri, 21 Jul 2023 10:58:13 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 4EB0D1000C3; Fri, 21 Jul 2023 10:58:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1689951492; bh=Iphep5yjGGUhKNdGFPMQpTfCkcU85DLJkHA0LGp2iMo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=aPG3vw2YapczBQl0JFR4xDYlTXNXig8QO8hmwyQi68ZBcwCwD1YLB3Q14UGFEf0U/ LiTIJ03Ium0Grj30Q4hJYWpV7JTtoktI3Tn4PIBlFadP8enHSfqsqtpst0BqL0rIhp 5g5vheWFG7Q953Ob0KyaMnMOpXwcBwowFTnVEu+Is+VyZv2EeKiate810Wl+5KYP7C KFsXc3b7pweh08goe5nuNba3CFFSFcX6Zfqtmvl1lDPthu6JXPZVBsoa/PlgrnD/PZ NLsVxLGE68MJN/QIGsiCvbK7UwGql76GA88BJpUeHHSlG6QFNHyHcpAtq5bkPGsY45 qIE+pa9Bth6VQ== Received: from alfajor (unknown [23.233.149.155]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 0DD7C12043B; Fri, 21 Jul 2023 10:58:12 -0400 (EDT) From: Stefan Monnier In-Reply-To: <87tttx7leo.fsf@localhost> (Ihor Radchenko's message of "Fri, 21 Jul 2023 07:50:55 +0000") Message-ID: References: <87bkg81j0i.fsf@localhost> <83fs5j4zti.fsf@gnu.org> <878rbarjuv.fsf@localhost> <83pm4m3mkh.fsf@gnu.org> <87tttx7leo.fsf@localhost> Date: Fri, 21 Jul 2023 10:58:11 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.307 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Ihor Radchenko [2023-07-21 07:50:55] wrote: > Eli Zaretskii writes: > >>> So, there is no problem with this section of the manual. The problem is >>> that manual does not describe the behavior with invisible text >>> boundaries I was trying to figure out. >> >> Which aspects of the behavior you describe are not mentioned in the >> manual. It does refer to invisible text. > > It talks about "in the middle of a sequence .. that ... is invisible" > > Emacs cannot display the cursor when point is in the middle of a > sequence of text that has the =E2=80=98display=E2=80=99 or =E2=80=98c= omposition=E2=80=99 property, or is > invisible. Therefore, after a command finishes and returns to the > command loop, if point is within such a sequence, the command loop > normally moves point to the edge of the sequence, making this sequence > effectively intangible. > > The situation I encountered is when point ends up not in the middle, but > already on the edge. So, Emacs moving point to _other_ edge was > surprising. How 'bout the rephrasing below? Stefan diff --git a/doc/lispref/commands.texi b/doc/lispref/commands.texi index 037f42124cc..ca009d97b39 100644 --- a/doc/lispref/commands.texi +++ b/doc/lispref/commands.texi @@ -1253,12 +1253,13 @@ Adjusting Point @cindex @code{display} property, and point display @cindex @code{composition} property, and point display =20 - Emacs cannot display the cursor when point is in the middle of a -sequence of text that has the @code{display} or @code{composition} -property, or is invisible. Therefore, after a command finishes and -returns to the command loop, if point is within such a sequence, the -command loop normally moves point to the edge of the sequence, making this -sequence effectively intangible. + When point is in the middle of a sequence of text that has the +@code{display} or @code{composition} property, or is invisible, Emacs +there can be several buffer positions that result in the cursor being +displayed at same place. Therefore, after a command finishes and +returns to the command loop, if point is in such a sequence, the +command loop normally moves point to one of the two edges of the +sequence, making this sequence effectively intangible. =20 A command can inhibit this feature by setting the variable @code{disable-point-adjustment}: From unknown Sun Jun 15 08:58:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#64724: 30.0.50; Inconsistency between manual, comments in the code, and implementation of point adjustment Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 21 Jul 2023 15:15:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64724 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: yantar92@posteo.net, 64724@debbugs.gnu.org Received: via spool by 64724-submit@debbugs.gnu.org id=B64724.168995248118167 (code B ref 64724); Fri, 21 Jul 2023 15:15:01 +0000 Received: (at 64724) by debbugs.gnu.org; 21 Jul 2023 15:14:41 +0000 Received: from localhost ([127.0.0.1]:34499 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMrq5-0004iw-1i for submit@debbugs.gnu.org; Fri, 21 Jul 2023 11:14:41 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58682) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMrq3-0004ik-8F for 64724@debbugs.gnu.org; Fri, 21 Jul 2023 11:14:39 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qMrpw-0002CV-Uv; Fri, 21 Jul 2023 11:14:32 -0400 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=O82ywRWudjgFY/YQwXfs/CPxvbQDYG9DVyz8OoKLx5U=; b=sWq2/Y/+Rvl1 X+IFk/t6lona7Ub9g5Z/ljaPKiRVj6oInxQizI7SbgF9XxsF9xIq0ex7LdyfAklw9gUKoK3OabhuU ki3lp2hMKlkT4xgojybaLPQyUukyktENEo6/YR5X+/W7F6IUdTlJtlewFev2NQXxOF1J/iWpIbg07 2RZzRDjeZi5Zrvt1PSisP8wA+m0N7wW1JYM43muVfmJQ4ZTXYtbXDMBjy+PGyFOHS5HyobdH8mKpA 5pkBfoOedsVEQrJIENMjJwFQ9YQL4eWkYZCy9G/wyW8E7i80LfXZ1VicWIzPt7FEvfsYcYMXi914k GUVPkoGT73pshaPqo3eYJw==; Received: from [87.69.77.57] (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 1qMrpw-0008Vy-7a; Fri, 21 Jul 2023 11:14:32 -0400 Date: Fri, 21 Jul 2023 18:15:09 +0300 Message-Id: <834jlxb8jm.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Stefan Monnier on Fri, 21 Jul 2023 10:58:11 -0400) References: <87bkg81j0i.fsf@localhost> <83fs5j4zti.fsf@gnu.org> <878rbarjuv.fsf@localhost> <83pm4m3mkh.fsf@gnu.org> <87tttx7leo.fsf@localhost> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: Eli Zaretskii , 64724@debbugs.gnu.org > Date: Fri, 21 Jul 2023 10:58:11 -0400 > > - Emacs cannot display the cursor when point is in the middle of a > -sequence of text that has the @code{display} or @code{composition} > -property, or is invisible. Therefore, after a command finishes and > -returns to the command loop, if point is within such a sequence, the > -command loop normally moves point to the edge of the sequence, making this > -sequence effectively intangible. > + When point is in the middle of a sequence of text that has the > +@code{display} or @code{composition} property, or is invisible, Emacs ^^^^^ That "Emacs" is redundant. > +there can be several buffer positions that result in the cursor being > +displayed at same place. ^^^^^^^^^^^^^ I'd say "at the same place on screen". From unknown Sun Jun 15 08:58:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#64724: 30.0.50; Inconsistency between manual, comments in the code, and implementation of point adjustment Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 22 Jul 2023 06:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64724 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: Eli Zaretskii , 64724@debbugs.gnu.org Received: via spool by 64724-submit@debbugs.gnu.org id=B64724.169000642126208 (code B ref 64724); Sat, 22 Jul 2023 06:14:01 +0000 Received: (at 64724) by debbugs.gnu.org; 22 Jul 2023 06:13:41 +0000 Received: from localhost ([127.0.0.1]:35304 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qN5s5-0006oe-C1 for submit@debbugs.gnu.org; Sat, 22 Jul 2023 02:13:41 -0400 Received: from mout02.posteo.de ([185.67.36.66]:52579) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qN5s1-0006oP-Px for 64724@debbugs.gnu.org; Sat, 22 Jul 2023 02:13:39 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id C1886240101 for <64724@debbugs.gnu.org>; Sat, 22 Jul 2023 08:13:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1690006411; bh=GRwR95E0Z1ie3ZfOIZZg7lrPoTfa4QU9PtVitAcpC0s=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=Q9wVgmqmce6HGnMwomCIqtETKOor4uFYB2gyF5dAKstIm2tejRFWNA0jrXYxiVVwh qfZlMZJSLmq0BGNQSMjjGd+Fl4uXbMRH19HFRkjYEaaBxIfKwU0U1LBTz7GUosnkPY Fyg2z6NgF4gZQxD/27ThXJyjDlY0AM+YR2LcZUpQnkZfK13HM1qcGnwo7pFHUkvH4b 1+2QiJpq99wS1SvzcDE4OxiWkgkYJSAF79u2x+wbdlPw9yzXXoKrkuPnessw/OnvVL DNSKaCiRf0nuLu7dF489svV93NdFmBz+z0ZdB1cAkMPuGp/NNhXe7+NUKNjgy8qnlR 2g484pqRQU65A== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4R7GMG3j1Yz9s0B; Sat, 22 Jul 2023 08:13:30 +0200 (CEST) From: Ihor Radchenko In-Reply-To: References: <87bkg81j0i.fsf@localhost> <83fs5j4zti.fsf@gnu.org> <878rbarjuv.fsf@localhost> <83pm4m3mkh.fsf@gnu.org> <87tttx7leo.fsf@localhost> Date: Sat, 22 Jul 2023 06:13:37 +0000 Message-ID: <87edl0a2y6.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Stefan Monnier writes: > + When point is in the middle of a sequence of text that has the I still find "in the middle of a sequence" confusing. > +@code{display} or @code{composition} property, or is invisible, Emacs > +there can be several buffer positions that result in the cursor being > +displayed at same place. Therefore, after a command finishes and > +returns to the command loop, if point is in such a sequence, the > +command loop normally moves point to one of the two edges of the > +sequence, making this sequence effectively intangible. > > A command can inhibit this feature by setting the variable > @code{disable-point-adjustment}: > -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From unknown Sun Jun 15 08:58:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#64724: 30.0.50; Inconsistency between manual, comments in the code, and implementation of point adjustment Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 22 Jul 2023 13:59:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64724 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , yantar92@posteo.net Cc: 64724@debbugs.gnu.org Received: via spool by 64724-submit@debbugs.gnu.org id=B64724.169003428430260 (code B ref 64724); Sat, 22 Jul 2023 13:59:01 +0000 Received: (at 64724) by debbugs.gnu.org; 22 Jul 2023 13:58:04 +0000 Received: from localhost ([127.0.0.1]:37373 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qND7U-0007s0-DX for submit@debbugs.gnu.org; Sat, 22 Jul 2023 09:58:04 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:21357) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qND7T-0007rT-5t for 64724@debbugs.gnu.org; Sat, 22 Jul 2023 09:58:03 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id B4DBD1000C4; Sat, 22 Jul 2023 09:57:57 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 63BAA10001F; Sat, 22 Jul 2023 09:57:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1690034272; bh=IVPjMOZE2M0o2eQGoFdv6agRam0dZ4qyKj+hdJfMkfY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=OpCEC17Maz5pV22YTiZonCmr3AI+8UNlYVRJLvKyMCgp0sYhwBr6As8Gy/LB3P0xX Xz6z5lKQaEn0J2oz2Vjygb3nt1++MWaHWOkOxPJUyYLNaBJKKxFqkwJdzy2tgqejvi 3OZ87U5JmqrqUJzGi/rry9ZnKyL0y5HJwVsLNzq4AvzhF04uS+dXb34cEGNydvGLFh CXuBLgxqD2qFaPHvLQhPQUBa9EVdBY2rFE5jxq6bil3p0na0J80BCJXi0wBVMD/3q+ mEB9QagG306aOLueDTdsOGBmb6pmWt1P402MZ6wAp1LK9Eprclt0GMRT9GFQvWb7Pj ne2Xzz4CUpFmg== Received: from pastel (unknown [104.247.231.138]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 381D41201CA; Sat, 22 Jul 2023 09:57:52 -0400 (EDT) From: Stefan Monnier In-Reply-To: <834jlxb8jm.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 21 Jul 2023 18:15:09 +0300") Message-ID: References: <87bkg81j0i.fsf@localhost> <83fs5j4zti.fsf@gnu.org> <878rbarjuv.fsf@localhost> <83pm4m3mkh.fsf@gnu.org> <87tttx7leo.fsf@localhost> <834jlxb8jm.fsf@gnu.org> Date: Sat, 22 Jul 2023 09:57:51 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.089 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) 2nd try! Stefan diff --git a/doc/lispref/commands.texi b/doc/lispref/commands.texi index 037f42124cc..ae379c664d4 100644 --- a/doc/lispref/commands.texi +++ b/doc/lispref/commands.texi @@ -1253,12 +1253,13 @@ Adjusting Point @cindex @code{display} property, and point display @cindex @code{composition} property, and point display - Emacs cannot display the cursor when point is in the middle of a -sequence of text that has the @code{display} or @code{composition} -property, or is invisible. Therefore, after a command finishes and -returns to the command loop, if point is within such a sequence, the -command loop normally moves point to the edge of the sequence, making this -sequence effectively intangible. + When a sequence of text has the @code{display} or @code{composition} +property, or is invisible, there can be several buffer positions that +result in the cursor being displayed at same place on the screen. +Therefore, after a command finishes and returns to the command loop, +if point is in such a sequence, the command loop normally moves point +to one of the two edges of the sequence, making this sequence +effectively intangible. A command can inhibit this feature by setting the variable @code{disable-point-adjustment}: From unknown Sun Jun 15 08:58:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#64724: 30.0.50; Inconsistency between manual, comments in the code, and implementation of point adjustment Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 23 Jul 2023 06:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64724 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: Eli Zaretskii , 64724@debbugs.gnu.org Received: via spool by 64724-submit@debbugs.gnu.org id=B64724.16900952413514 (code B ref 64724); Sun, 23 Jul 2023 06:54:02 +0000 Received: (at 64724) by debbugs.gnu.org; 23 Jul 2023 06:54:01 +0000 Received: from localhost ([127.0.0.1]:37865 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qNSyf-0000uc-4y for submit@debbugs.gnu.org; Sun, 23 Jul 2023 02:54:01 -0400 Received: from mout01.posteo.de ([185.67.36.65]:47169) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qNSyc-0000uP-Sd for 64724@debbugs.gnu.org; Sun, 23 Jul 2023 02:54:00 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 3EBB9240028 for <64724@debbugs.gnu.org>; Sun, 23 Jul 2023 08:53:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1690095233; bh=EvILniyOszJu6ulJoQpxPbLkYcp2vGq7Ef6aPf+9hzQ=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=Dp/GgADjM63Dtq5oJp1mQGfZjgApxLCyldzU0SSD6O9ZwV5wPXOZ7NrkY7pH2C8Ua e/1qbxixscHrgsyFP9pjYUYZAzWsRK6piTjZUoXZbNW9op1YMTaXeUPFItigFmArwP 6wYipzemKum2Kr8eFg0aj0JOzkTEsvamemGlBfOhw4/kr1iERKYPmiVUpkU6Sd5Bit mrOFd5J3d8ajS8qLpxD67vOkEMv5UZISuS/6kHWlPFXgMt1BZ0EwlnyNfbmKgt3l0R B9CF4mZfmkUoO2Ui0XvviYdEx7Xq+Q+JVHmG4IJHMyMdqH0OZ0zT/wyJPoPT70VzWy 6mCSO8BVZPELQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4R7vCN36Rgz6tv5; Sun, 23 Jul 2023 08:53:51 +0200 (CEST) From: Ihor Radchenko In-Reply-To: References: <87bkg81j0i.fsf@localhost> <83fs5j4zti.fsf@gnu.org> <878rbarjuv.fsf@localhost> <83pm4m3mkh.fsf@gnu.org> <87tttx7leo.fsf@localhost> <834jlxb8jm.fsf@gnu.org> Date: Sun, 23 Jul 2023 06:54:05 +0000 Message-ID: <87h6pvrucy.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Stefan Monnier writes: > 2nd try! Thanks! This sounds better. Although, I would also specifically mention that adjustment can happen even when point is already at the edge. To make sure that it is 100% clear. And should the detail about stickiness be documented? Or do you want to leave this as unspecified behaviour? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at