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, 25 Jul 2023 15:37:52 +0300 Message-ID: <83zg3kp3of.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> <83bkg1sbg7.fsf@gnu.org> <87zg3kqtbl.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="1861"; 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 25 14:38:30 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 1qOHJ7-0000GP-Uf for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 25 Jul 2023 14:38:30 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qOHIi-0003MN-2v; Tue, 25 Jul 2023 08:38: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 1qOHIg-0003LT-PE for bug-gnu-emacs@gnu.org; Tue, 25 Jul 2023 08:38: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 1qOHIg-00039d-EM for bug-gnu-emacs@gnu.org; Tue, 25 Jul 2023 08:38:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qOHIg-00042b-AY for bug-gnu-emacs@gnu.org; Tue, 25 Jul 2023 08:38: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: Tue, 25 Jul 2023 12:38: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.169028865315494 (code B ref 64696); Tue, 25 Jul 2023 12:38:02 +0000 Original-Received: (at 64696) by debbugs.gnu.org; 25 Jul 2023 12:37:33 +0000 Original-Received: from localhost ([127.0.0.1]:44839 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qOHIC-00041q-PK for submit@debbugs.gnu.org; Tue, 25 Jul 2023 08:37:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36620) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qOHIA-00041d-T8 for 64696@debbugs.gnu.org; Tue, 25 Jul 2023 08:37:31 -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 1qOHI3-000364-Fv; Tue, 25 Jul 2023 08:37:24 -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=yu1VUrOBm71qwC3STeSl5QwCuDrZ1CJ+bEPhjbwAWMM=; b=AIekU9s2CCEV+aZUCijH tE1FdOKIZzv0kNKVNZZkEaNwfbpCCw/2rcAv+LlhuAckbwylWDoCE3iGJvnSaFcRzcdUY/DcPjwoW 06bcqfeSK7I5PriyCK3bhGqlccdH2+Q9v/eer/jZjExYYOua9KIbtAoOQ6Jgsnu7n0pjoPMRIQGPg jfVD1lDyBDl/md+it7WIx+H0QN64uG+pBlSuWQD8I6JU2KlA7pvymJO7crD/rEebvkfVNJPwnDmkv tYK9bYNVdvw6u0mZDpMbruZAgjeJ+VjGzMbyEBGa9kVx6lMRUClFFF50PJ3M3I0tdrginwd1OJETA x18RM1Y2x6WaYA==; 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 1qOHHm-00043L-OF; Tue, 25 Jul 2023 08:37:19 -0400 In-Reply-To: <87zg3kqtbl.fsf@localhost> (message from Ihor Radchenko on Tue, 25 Jul 2023 08:38:38 +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:266052 Archived-At: > From: Ihor Radchenko > Cc: monnier@iro.umontreal.ca, 64696@debbugs.gnu.org > Date: Tue, 25 Jul 2023 08:38:38 +0000 > > Eli Zaretskii writes: > > >> 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? > > "*" is made invisible after fontification. So these are not font-lock-* faces, right? > > 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. > > I can see your point. However, this is sometimes conflicting with > copying text verbatim or viewing it in other editors. For example, > nameless-mode that visually compresses > my-long-package-name-variable-name into :variable-name creates a lot of > mess when the same file is committed to public repo and later opened by > other contributors without nameless-mode enabled. This might mean we need more intelligent commands that copy text elsewhere. However, note that it is OK for Emacs to expect other software/media to share at least some of the visual features. For example, I have yet to see a text-rendering program that doesn't show diacritics composed with the base characters, and most show Emoji as you'd expect, not as a series of control codes. OTOH, tabs could be shown differently, especially if tab-width was customized. But I think this is a relatively far tangent, as it is not immediately related to indentation in Emacs itself. In Emacs, indentation is a display-oriented feature, so the few programming languages where indentation is syntactically and semantically meaningful must do something special when the buffer uses non-trivial Emacs display features beyond tab expansion. Invisible text, in particular, doesn't go along well with such use cases. > In the ideal world, Emacs would indent both visually and textually. I disagree that this is the ideal. "Textual" indentation is not indentation at all, it is fundamentally a completely different feature for completely different purposes. Even if we agree that Emacs should have it (and I don't yet agree), you shouldn't expect from the Emacs indentation to fill this niche, except by sheer luck in some use cases. > With visual part only using 'display text properties that do not > modify the actual text in file. This will (a) not help you, because the issue of width of the whitespace stretches will still be pertinent; and (b) will complicate Emacs much more, because copying such "text" will become much more tricky in general. But if you want to work on adding this, please feel free. It has its uses, even for indentation; see, for example, pixel-fill.el. It is on our TODO to provide pixel-granularity indentation for text using variable-pitch fonts (but this again is for visual appearance only). > >> A toggle: disable all visual contributors. > > > > It will never be used. > > I would use it in Org instead of `org-current-text-column'. So we have one user. And even in your case, you don't want them all disabled: the character compositions, for example, should stay turned ON. > may not hold in future (the docstring implies that `string-width' may as > well consider visuals: "Return width of STRING when displayed in the > current buffer.") Selective citation alert! The full text of the doc string is: Return width of STRING when displayed in the current buffer. Width is measured by how many columns it occupies on the screen. Optional arguments FROM and TO specify the substring of STRING to consider, and are interpreted as in ‘substring’. When calculating width of a multibyte character in STRING, only the base leading-code is considered; the validity of the following bytes is not checked. Tabs in STRING are always taken to occupy ‘tab-width’ columns. The effect of faces and fonts used for non-Latin and other unusual characters (such as emoji) is ignored as well, as are display properties and invisible text. For these reasons, the results are not generally reliable; for accurate dimensions of text as it will be displayed, use ‘window-text-pixel-size’ instead. What else do you want us to say, for you to understand that the "visual" part here is quite limited?