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: Sun, 23 Jul 2023 13:05:30 +0300 Message-ID: <83wmyrt02d.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> <83bkg481g5.fsf@gnu.org> <87bkg3rso5.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22775"; 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 Sun Jul 23 12:06:20 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 1qNVyl-0005g3-ER for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 23 Jul 2023 12:06:19 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qNVyd-00058f-2z; Sun, 23 Jul 2023 06:06:11 -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 1qNVya-00058P-TO for bug-gnu-emacs@gnu.org; Sun, 23 Jul 2023 06:06:08 -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 1qNVyU-0004GO-II for bug-gnu-emacs@gnu.org; Sun, 23 Jul 2023 06:06:08 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qNVyU-0000Uy-Dd for bug-gnu-emacs@gnu.org; Sun, 23 Jul 2023 06:06:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 23 Jul 2023 10:06:02 +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.16901067101855 (code B ref 64696); Sun, 23 Jul 2023 10:06:02 +0000 Original-Received: (at 64696) by debbugs.gnu.org; 23 Jul 2023 10:05:10 +0000 Original-Received: from localhost ([127.0.0.1]:38435 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qNVxd-0000Tr-P8 for submit@debbugs.gnu.org; Sun, 23 Jul 2023 06:05:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35680) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qNVxb-0000TX-IK for 64696@debbugs.gnu.org; Sun, 23 Jul 2023 06:05:08 -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 1qNVxW-0003tr-67; Sun, 23 Jul 2023 06:05:02 -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=Fr4fLrtQntNfFBPer3YL/FiP8xPt6TBZvMyJ98/b4fo=; b=RViD5yL9fld1O/WQrvGi h0RVte5mz+rwjKPnXAxn2xvnYOI2dHcg8s8xfsI1+jo4s8KObrcTlVx3EelzD6zkfeIXwdvsKYv1H I33vl4T73vcnCoBxyeznHiGx2qgI/dfVvwukeoVLRjaCYwnQcm7ldJIK30mUoD1a3FaytS/KocHXq ElF2AVuuVk9W7Q+joaRnBVlxGUdElj0g0NSqCPgffMDtzQWjwxhfWN/rW5eBQNKx8Dv3dcrSAxm7T f690m+4zfdj/pylGY6GF8hB/ZUXJda7r0xrJSZFyz4druI+UlgaAtRzlLDE9zCxOmdppOOMNtjgqS i9GXy1b6VeXL+Q==; 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 1qNVxJ-0002MZ-Sa; Sun, 23 Jul 2023 06:05:01 -0400 In-Reply-To: <87bkg3rso5.fsf@localhost> (message from Ihor Radchenko on Sun, 23 Jul 2023 07:30:34 +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:265884 Archived-At: > From: Ihor Radchenko > Cc: monnier@iro.umontreal.ca, 64696@debbugs.gnu.org > Date: Sun, 23 Jul 2023 07:30:34 +0000 > > On one hand, Emacs' indentation is nicely aligning text as is it > actually displayed in the buffer, taking into account all kinds of bells > and whistles that alter the displayed text width. > > On the other hand, such visual indentation is not always good. Visuals > present in one Emacs config may not be enabled in another config. And > code/text nicely aligned on one machine will suddenly look ugly on > other. For example, see > http://endlessparentheses.com/using-prettify-symbols-in-clojure-and-elisp-without-breaking-indentation.html Programs that want "indentation" that only counts codepoints (which is really a rare situation, see below) need to disable all kinds of Emacs features, otherwise they will not get what they want. > In Org mode, visual indentation is also not necessarily good thing: > > 1. Org mode is generally aiming for the produced Org files to be > readable as unfontified plain text. So, quirks related to visual > indentation generally tend to mess things up. "Unfontified"? AFAIK, Org files do use fontifications, don't they? So what do you mean by "unfontified plain text" here? But that's an aside, feel free to ignore. > 2. Org mode uses indentation as part of the syntax. I had to get rid of > using `current-column' and calculated "true textual indentation" > manually to avoid breakage after `current-column' started to take > into account invisibility. (bug#56837) This cannot be avoided. Emacs provides by default many features that "mess up" this kind of "true textual indentation". Some of these features include: . character composition . tab expansion . display properties that hide text and display some other text . display properties that align text . faces that affect character metrics via fonts . invisible text (I'm probably missing some more.) Only the Lisp program knows which of those are relevant to the particular application at hand. For example, in your "true textual indentation", how do you account for U+0061 LATIN SMALL LETTER A followed by U+0301 COMBINING ACUTE ACCENT? They are almost always displayed as a single glyph: á. Do you consider this a single column or 2 columns? What about long Emoji sequences? We could introduce separate indentation/current-column knobs for each of the above features, but it would make little sense to me, since most, if not all, of them already have such knobs. For example, character composition can be disabled by flipping a variable. > > 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. > > That would make sense, yes. > > > 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. > > What about having something like `current-visual-column' that will be > used when we really need to examine which display column the cursor is > it, accounting for all the display-affecting properties? > > Or maybe even have `use-visual-columns' variable that will modify how > `current-column' behaves ('visual, 'textual, 'visual-ignore-invisible, > etc) See above: you are actually opening a Pandora box, and any solution will likely be based on existing variables. So I think we already have what you want, it just might not be immediately obvious in each case which of the knobs to use. The default behavior of current-column can already be affected by disabling auto-composition-mode, by tweaking the buffer's invisibility spec, and by defining display properties whose values are conditional. Tab expansion can also be controlled. What else would make sense?