From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#64696: 30.0.50; indent-to inherits preceding text properties, including 'invisible Date: Tue, 18 Jul 2023 16:10:21 +0300 Message-ID: <83351l74ci.fsf@gnu.org> References: <87fs5l3b3g.fsf@localhost> <83ilah79aq.fsf@gnu.org> <87jzux2zg8.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29268"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, 64696@debbugs.gnu.org To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jul 18 15:11:13 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qLkTw-0007OV-Al for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 18 Jul 2023 15:11:12 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qLkTo-0001f8-R3; Tue, 18 Jul 2023 09:11:04 -0400 Original-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 1qLkTl-0001ey-Vs for bug-gnu-emacs@gnu.org; Tue, 18 Jul 2023 09:11:02 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qLkTl-0005dc-N5 for bug-gnu-emacs@gnu.org; Tue, 18 Jul 2023 09:11:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qLkTl-0003m2-IN for bug-gnu-emacs@gnu.org; Tue, 18 Jul 2023 09:11:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 18 Jul 2023 13:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64696 X-GNU-PR-Package: emacs Original-Received: via spool by 64696-submit@debbugs.gnu.org id=B64696.168968581214444 (code B ref 64696); Tue, 18 Jul 2023 13:11:01 +0000 Original-Received: (at 64696) by debbugs.gnu.org; 18 Jul 2023 13:10:12 +0000 Original-Received: from localhost ([127.0.0.1]:52098 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qLkSr-0003km-Cu for submit@debbugs.gnu.org; Tue, 18 Jul 2023 09:10:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34558) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qLkSp-0003k8-6E for 64696@debbugs.gnu.org; Tue, 18 Jul 2023 09:10:03 -0400 Original-Received: from fencepost.gnu.org ([209.51.188.10]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qLkSh-0005DC-St; Tue, 18 Jul 2023 09:09:57 -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=PBy881hPgyViIZMmoS1gDh0Tzmnh4nag5nRdJuOc9JU=; b=m2Tnt1zZ3ix2Rp6SuHmJ tlqW3QGBivdQSpFo6ZpGdLe471YTT355Bxwm7V2lOYqgBk3SjejN+LSVl90RS2vh5VT+dGRF2dWNM UcTfRhL1NGtbGVNXfKbFhPM4qR5YFw3mePgnQjAxNAqVfdPqxo+meP8teV1nf3V5Rmv96Z+yNkFak 0twav6Idchxylr6Kznzk/wnRN5cKnCnnDKTu/Z/enRUIITzfaaCvTu6TI0HBAa721A2dNYWiBmARq w+1tyAIHQJ874dM2tP93/tFfCiI1BD7gpsnlOxgrTLyUL04cTcP8zIBjI6R2WudcS9xaJZaKrE3QG AEVDqePh8neesw==; Original-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 1qLkSf-0004CI-7z; Tue, 18 Jul 2023 09:09:55 -0400 In-Reply-To: <87jzux2zg8.fsf@localhost> (message from Ihor Radchenko on Tue, 18 Jul 2023 12:09:43 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:265460 Archived-At: > From: Ihor Radchenko > Cc: Stefan Monnier , 64696@debbugs.gnu.org > Date: Tue, 18 Jul 2023 12:09:43 +0000 > > Eli Zaretskii writes: > > > Whether the inherited properties should also include the invisible > > property could be subject to discussion, but it isn't 100% clear to me > > that it should always be excluded. > > The problem is that inheriting 'invisible (if its value is actually > hiding text) yields to cursor not moving to the target column. > > When I read the docstring: > > (indent-to COLUMN &optional MINIMUM) > > Documentation > Indent from point with tabs and spaces until COLUMN is reached. > > I expect that (current-column) will become COLUMN after calling > `indent-to'. It is not the case in the described scenario. If the problem is documentation, we can easily augment the documentation to match the actual behavior. So let's first discuss the behavior, not what the documentation says. > More generally, `indent-to' implementation assumes that it is sufficient > to insert "COLUMN - (current-column)" spaces in order to reach COLUMN > (let me ignore tabs for simplicity). But ignoring the tabs is not a valid "trick" here, because it exactly means that your interpretation is too naïve: there's more in indentation to a certain column than meets the eye, precisely because of stuff like tabs, display properties, composed characters, and other calamities. > And the actual scenario for Org is even more complex because > Org fontification is what is adding that problematic invisible text > property, leading to race condition between redisplay and indentation. > When I sprinkled (redisplay) calls to different places in Org's > tag alignment code, the results varied depending on where the > (redisplay) call was inserted. there couldn't be any race condition here, because indent-to is not run when redisplay runs. I guess you mean that one could see the indentation appear, then disappear as result of JIT fontifications, or not appear at all, depending on the details? > > In any case, I think you can bind text-property-default-nonsticky > > around the indent-to call to control this, right? Or use the > > rear-sticky text property. > > That's what I did to fix things on Org side, but I believe that the > current behaviour is a genuine bug. "Bug" in what sense? Do you mean that indenting should disregard properties completely? or just the invisible property? or something else? indent-to is a general-purpose primitive, so any change there will affect gobs of Emacs Lisp programs, and we must specify the desired behavior in a lot of detail in order to be able to discuss such changes.