From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.bugs Subject: bug#64696: 30.0.50; indent-to inherits preceding text properties, including 'invisible Date: Thu, 27 Jul 2023 08:58:54 +0000 Message-ID: <87fs597msx.fsf@localhost> References: <87fs5l3b3g.fsf@localhost> <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> <83zg3kp3of.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2317"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, 64696@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jul 27 11:32:45 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 1qOxMS-0000JN-3R for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 27 Jul 2023 11:32:44 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qOwps-00049x-OT; Thu, 27 Jul 2023 04:59: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 1qOwpr-00049l-3y for bug-gnu-emacs@gnu.org; Thu, 27 Jul 2023 04:59: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 1qOwpq-0001WY-ST for bug-gnu-emacs@gnu.org; Thu, 27 Jul 2023 04:59:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qOwpq-0002Q1-Fj for bug-gnu-emacs@gnu.org; Thu, 27 Jul 2023 04:59:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 27 Jul 2023 08:59: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.16904483329281 (code B ref 64696); Thu, 27 Jul 2023 08:59:02 +0000 Original-Received: (at 64696) by debbugs.gnu.org; 27 Jul 2023 08:58:52 +0000 Original-Received: from localhost ([127.0.0.1]:40726 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qOwpf-0002Pd-Mp for submit@debbugs.gnu.org; Thu, 27 Jul 2023 04:58:52 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]:48517) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qOwpd-0002PP-8x for 64696@debbugs.gnu.org; Thu, 27 Jul 2023 04:58:50 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 711BD240027 for <64696@debbugs.gnu.org>; Thu, 27 Jul 2023 10:58:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1690448323; bh=n4YQ4bQEyuYXujvz/t85LH8MZBgeA7w1GbBbffUNgKo=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:From; b=lKfRj3ybg3Q+hxVbKTftIoGzevxO+QaC5ZtW8QdM6q58yz69UvtIaB1OXa6UzFyhD pWcrXNLVzx9bObXY89Ok+CQb0Epo7IMjl95jWhaU8uC4j64H7Qb0Euo4gfvDvX8xNs +P/5aKStpvNdlC4WflDCteRfTZSZ0TbspOTJVFi8co0PVlQYN5eb3EcJsPoDLE17re 7fUrOKnsrZXz98VVELAf2CiyW7AVowGPlXGs2zyDVOn42mz13U9b9QYP7/gN4Dp2L4 EOOrg1Z7T7BohCcIQI47piMvHiLJQsouybBRFigyB4eyMTOw1RnS4WHUqPq/VFszKe QUE41UeGggskg== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RBPnX62F7z6tvy; Thu, 27 Jul 2023 10:58:40 +0200 (CEST) In-Reply-To: <83zg3kp3of.fsf@gnu.org> 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:266178 Archived-At: Eli Zaretskii writes: >> 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. Got it. >> 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. I am not sure if I understand the problem with copying. Certain text properties are already ignored when copying anyway. > 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). I did some preliminary work in Org mode. For example, I tried to right-align tags like |left fringe|* Heading :tag:|right fringe| Using :align-to space spec and font-lock-keywords. This can work, although it is unfortunate that there is no "stretch" space that will automatically occupy as much space as possible without pushing the line across right fringe. Org also provides org-indent-mode that uses text properties to align text visually. >> 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. Sure. Especially if the composition is dictated by UTF standard. >> 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 =E2=80=98substring=E2=80=99. > > 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 =E2=80=98tab-width=E2=80=99 columns. The effect of fac= es 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 =E2=80=98window-text-pixel-size=E2=80=99 instead. > > What else do you want us to say, for you to understand that the > "visual" part here is quite limited? It is clear that it is limited, but I am concerned that there are still some display features (and possibly display features added in future) that may change the behavior. I think that the main source of the confusion is the first line "Return width of STRING when displayed in the current buffer", which sounds like certain buffer-specific display things are affecting the result. --=20 Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at