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: Sat, 22 Jul 2023 17:28:58 +0300 Message-ID: <83bkg481g5.fsf@gnu.org> References: <87fs5l3b3g.fsf@localhost> <83ilah79aq.fsf@gnu.org> <87jzux2zg8.fsf@localhost> <83351l74ci.fsf@gnu.org> <87a5vt2vx8.fsf@localhost> <831qh56vvz.fsf@gnu.org> <871qh52nlw.fsf@localhost> <83pm4p5er8.fsf@gnu.org> <874jm0mhgb.fsf@localhost> <831qh459sy.fsf@gnu.org> <87jzuvq785.fsf@localhost> <835y6ca1ah.fsf@gnu.org> <87zg3o8m2a.fsf@localhost> <83wmys8a2g.fsf@gnu.org> <87v8ecrqib.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13208"; 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 Sat Jul 22 16:29:19 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 1qNDbj-0003HV-7P for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 22 Jul 2023 16:29:19 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qNDbU-0005Nw-Lz; Sat, 22 Jul 2023 10:29:05 -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 1qNDbS-0005NZ-Hn for bug-gnu-emacs@gnu.org; Sat, 22 Jul 2023 10:29:03 -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 1qNDbS-0003Fp-AA for bug-gnu-emacs@gnu.org; Sat, 22 Jul 2023 10:29:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qNDbR-0000DI-Or for bug-gnu-emacs@gnu.org; Sat, 22 Jul 2023 10:29: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: Sat, 22 Jul 2023 14:29: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.1690036109774 (code B ref 64696); Sat, 22 Jul 2023 14:29:01 +0000 Original-Received: (at 64696) by debbugs.gnu.org; 22 Jul 2023 14:28:29 +0000 Original-Received: from localhost ([127.0.0.1]:37409 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qNDav-0000CQ-6D for submit@debbugs.gnu.org; Sat, 22 Jul 2023 10:28:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42620) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qNDat-0000CB-8C for 64696@debbugs.gnu.org; Sat, 22 Jul 2023 10:28:27 -0400 Original-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 1qNDan-00036P-E0; Sat, 22 Jul 2023 10:28:21 -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=UnC7qVTf+u30KKeiKYnRYgkVa+8cHkHT1DaYcBNMjCI=; b=ckkdnwRUgZbZ KjnrOxU35RwJMBTTgyEhf33pOoZi5+xI3CxoC1R/7B55lbkoO61oUhMuU0fClH4db4psH2dyZe5AE AwU0hYZkcuq82wU1RX1sv7pqeH9cPJehH5Wo5iYB5W1TBtYBFdULydocgjXHY/JpxNRBDqGYz3zdc w7oW2VkD4VsDgBP0LP8rEZk4QQysXTxkrkKED2hdlOGp+B4ApDB1nrMU2xfboiLem7UuzY+X6RrZW POqFDzFSxTMLSBY/R7avTVhLYJOVTa0aww3c9GRs2oS1/Vx1KvIYPG3fAUjVj7RiRYhWw8Af+08TR ZBuSJVECD44ZTRI8EBsohw==; 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 1qNDam-0003Dn-T5; Sat, 22 Jul 2023 10:28:21 -0400 In-Reply-To: <87v8ecrqib.fsf@localhost> (message from Ihor Radchenko on Sat, 22 Jul 2023 14:05:00 +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:265823 Archived-At: > From: Ihor Radchenko > Cc: monnier@iro.umontreal.ca, 64696@debbugs.gnu.org > Date: Sat, 22 Jul 2023 14:05:00 +0000 > > Eli Zaretskii writes: > > >> Test #2 is unexpected - we are inside invisible region, but > >> current-column reports as if everything were visible. > > > > current-column produces incorrect results when the newline before the > > current line is invisible. It always starts from the beginning of the > > current physical line, even if that is in invisible text. > > Then why does test #3 produce current-column = 0? > The newline before current line is also invisible there. I'm guessing it's sheer luck or something. Bugs are like that: they don't always behave consistently if you change the conditions slightly. I didn't look at that case, and frankly, I'm not thrilled to do that. The code starts by going to the previous newline, and doesn't pay attention to whether the newline is itself invisible. Thereafter, it looks only for _changes_ in the invisible property, so it will not consider a stretch of text starting from that newline as invisible. Given this strategy, it should be clear that the result cannot be correct in general when the newline at BOL is invisible; all the rest are details that are not really relevant, and spending time on understanding exactly what happens in this or that particular case is from my POV a waste of time. > > We could teach current-column about invisible newlines, see the patch > > below. But I'm not sure this is justified, nor whether it won't break > > something. The patch below also has a disadvantage that it will still > > behave as before for a buffer that is not displayed in any window; if > > we want that to be fixed as well, the changes will need to be more > > extensive. (Basically, we will need to write a non-display version of > > back_to_previous_visible_line_start.) > > > > With the patch below, Test #2 shows "current-column = 6", which is > > correct, since the cursor is shown after "* Test", with all the rest > > invisible. > > This will definitely break indentation code. But is correct, don't you agree? > Look at `indent-line-to': > > (beginning-of-line 1) > (skip-chars-forward " \t") > (let ((cur-col (current-column))) > <...> > ((> cur-col column) ; too far right (after tab?) > (delete-region (progn (move-to-column column t) (point)) > ;; The `move-to-column' call may replace > ;; tabs with spaces, so we can't reuse the > ;; previous start point. > (progn (beginning-of-line 1) > (skip-chars-forward " \t") > (point)))) This obviously assumes the text is not invisible. > I am pretty sure that it is not the only breakage. I don't insist in making that change. Quite the opposite, actually. I also expect it to break gobs of indentation code where invisible text is involved. Indentation code should probably temporarily remove the invisibility spec, while indenting, or something. Once again, the indentation feature was designed to work on PL source text and on human-readable text files where the user types text that is completely, or almost completely, visible. It was not designed for Outline and similar modes which hide large portions of the buffer text. So it is a small wonder that it doesn't work well in those cases. The main motivation to fix scan_for_column to consider more visual effects was so vertical cursor motion works as expected when large portions of text are hidden.