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: Mon, 24 Jul 2023 16:09:28 +0300 Message-ID: <83bkg1sbg7.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> <83wmyrt02d.fsf@gnu.org> <87edkx3eoh.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="8391"; 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 Mon Jul 24 15:13:56 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 1qNvNr-0001vf-05 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 24 Jul 2023 15:13:55 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qNvKZ-0000eZ-Ni; Mon, 24 Jul 2023 09:10:31 -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 1qNvKG-00008z-Cp for bug-gnu-emacs@gnu.org; Mon, 24 Jul 2023 09:10:12 -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 1qNvK6-0003Lg-8W for bug-gnu-emacs@gnu.org; Mon, 24 Jul 2023 09:10:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qNvK6-0007G0-2n for bug-gnu-emacs@gnu.org; Mon, 24 Jul 2023 09:10: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: Mon, 24 Jul 2023 13:10: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.169020415727837 (code B ref 64696); Mon, 24 Jul 2023 13:10:02 +0000 Original-Received: (at 64696) by debbugs.gnu.org; 24 Jul 2023 13:09:17 +0000 Original-Received: from localhost ([127.0.0.1]:42129 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qNvJG-0007En-Qr for submit@debbugs.gnu.org; Mon, 24 Jul 2023 09:09:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59172) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qNvJ5-0007E6-Jz for 64696@debbugs.gnu.org; Mon, 24 Jul 2023 09:09: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 1qNvIz-00032d-2E; Mon, 24 Jul 2023 09:08:53 -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=md9id+wG8eooQOf79Y9eiOxYFhRRVgQBXXG4IQJb93k=; b=KruU107aXuRfCgeQC3t1 c4hTOxHKSpEPntlXxblnqrUyYYb5fdiFCfsthajad7iPraGtgkAtCSC0dr6qBp3EpehfVcQL7FOqF ui5evbIDLbym6TYAtsuafeBa4UMbsWRM4QsMB0MTGNQXrGTDqkBYa6YOOH3cmnK/RVZl60l8z0Qnv JmnfhIavOwG5wpSJVPAStsPV1CAoDP+f6a/GFiKEwObF2L8KGi3rHfGLwP8UK2zfHaswfxHmlHNLD xHAgC9e4m1RfNIqVqwjeZXk36sOlbMzRlElT+JLFt4UXA3e8QD5S5NlijzSGZww6wWTJx7uzQ6OO0 VtSz3+vunDKL4g==; 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 1qNvIs-0005PL-Gf; Mon, 24 Jul 2023 09:08:52 -0400 In-Reply-To: <87edkx3eoh.fsf@localhost> (message from Ihor Radchenko on Mon, 24 Jul 2023 08:18:54 +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:265965 Archived-At: > From: Ihor Radchenko > Cc: monnier@iro.umontreal.ca, 64696@debbugs.gnu.org > Date: Mon, 24 Jul 2023 08:18:54 +0000 > > Eli Zaretskii writes: > > >> 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. > > For example, consider an Org table like > > | *This* | is | some text | > | more | | text | > > It looks aligned in Org buffers ("*" is invisible), but not when copied > to message buffer. Where does fontification enter this picture? > >> 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: > > ... > > (I'm probably missing some more.) Only the Lisp program knows which > > of those are relevant to the particular application at hand. > > Sure, but how can an application, say, disable all the effects of visual > representation without (1) searching and let-binding each specific > toggle (and possibly adding more in future versions of Emacs); (2) > re-implementing the existing indentation code (like what > `org-current-text-column' does)? It can't. But then it also doesn't want to. In practice, most of these features should not be turned off, because either the text will become illegible, or the indentation performed when the features are turned off will break when the text is displayed "normally". IOW, the tendency should be to provide _more_ visual indentation, by making our indentation commands smarter and more fine-grained (e.g., pixel-wise), not to make them _less_ visual by disabling the important display features. The important thing to remember is that Emacs makes all those display-time transformation because that's how people want to see the text on the screen. It is very rare to see an application that wants to show decomposed characters, as in a◌́ instead of á, or to see a TAB shown as a single column. Heck, even the display of control characters, like , is part of this, and why would we want to turn that off? IOW, the need for turning these off is extremely rare, and doesn't justify such global toggles, because no one will use them. > > 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. > > It would help to list what contributes to indentation/columns in the > documentation. They are a legion. Basically, every display-related feature described in the ELisp manual -- and there are a lot of them -- is of this nature. Since we already describe them all in the manual, adding a section which mentions them all together is strictly not necessary for a reference manual. It's more a job for a tutorial. You are asking that someone does a very large job of collecting existing stuff together, for facilitating a solution of some pretty rare problem. I cannot justify a large job such as this one -- going through all the Emacs display features and describing them together -- for this kind of purpose. But if someone wants to work on that, I won't necessarily object if the result is concise and doesn't repeat the existing material. > > 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? > > A toggle: disable all visual contributors. It will never be used.