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, 30 Jul 2023 20:11:51 +0300 Message-ID: <83mszd2ujs.fsf@gnu.org> References: <87fs5l3b3g.fsf@localhost> <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> <87fs597msx.fsf@localhost> <83a5vhn2ak.fsf@gnu.org> <877cqkfoip.fsf@localhost> <83jzukjlse.fsf@gnu.org> <87wmyjxfbt.fsf@localhost> <83cz0bm2hn.fsf@gnu.org> <87tttlj0r6.fsf@localhost> <83leexlny4.fsf@gnu.org> <873515hbcf.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4781"; 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 30 19:50:12 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 1qQAYV-0000z4-31 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 30 Jul 2023 19:50:11 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qQ9yb-0007qu-R8; Sun, 30 Jul 2023 13:13: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 1qQ9yY-0007qQ-QZ for bug-gnu-emacs@gnu.org; Sun, 30 Jul 2023 13:13: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 1qQ9yY-0003fx-61 for bug-gnu-emacs@gnu.org; Sun, 30 Jul 2023 13:13:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qQ9yX-0003ZD-Pp for bug-gnu-emacs@gnu.org; Sun, 30 Jul 2023 13:13: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: Sun, 30 Jul 2023 17:13: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.169073712113623 (code B ref 64696); Sun, 30 Jul 2023 17:13:01 +0000 Original-Received: (at 64696) by debbugs.gnu.org; 30 Jul 2023 17:12:01 +0000 Original-Received: from localhost ([127.0.0.1]:51179 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qQ9xZ-0003XZ-9G for submit@debbugs.gnu.org; Sun, 30 Jul 2023 13:12:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41402) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qQ9xW-0003XG-SJ for 64696@debbugs.gnu.org; Sun, 30 Jul 2023 13:12:00 -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 1qQ9xQ-0003Vg-Jg; Sun, 30 Jul 2023 13:11:52 -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=opRAsp0sdTomK89UCUceKfSB7qlddtbktWOkMpHvWpI=; b=SCu755jsQJNA tcLCqfufQkRR3T3CY+po6fW/uDLGfyNZFOyKIahxYAauQSXCv9/ODjRYIlW8Nv7SxWSUXe306iir/ eCFM5gtfUZMaIJpKlgZCSvCHz1lrnSTmSETCPsT/W06zP+Odr4LNeUcbveOmVzbCUl0uagaeTguhe gP2MtcReh3vT96O6/u0I7aBcAYaIDOI9q9EQhKtt3Z8myOCRXHhvlNSeagwYRZxBykXySHej5EDH8 v0uqAUv0YhEWmCX/qyz6kkLM7RvllMsNYbRT6LbFV2XLqQIN037v9sWJUzFkme0UrBRscN0ilQCYv CV0qYIKarp3zj6ic1kXaCg==; 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 1qQ9xP-00036u-Vs; Sun, 30 Jul 2023 13:11:52 -0400 In-Reply-To: <873515hbcf.fsf@localhost> (message from Ihor Radchenko on Sun, 30 Jul 2023 11:45:20 +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:266376 Archived-At: > From: Ihor Radchenko > Cc: monnier@iro.umontreal.ca, 64696@debbugs.gnu.org > Date: Sun, 30 Jul 2023 11:45:20 +0000 > > Eli Zaretskii writes: > > > There's a limit to which a doc string can describe every single > > subtlety of a non-trivial implementation, and still remain useful. If > > someone needs to know about these aspects (presumably because their > > Lisp program does something very special, because otherwise these > > things "just work"), they should either read the source or ask here, > > because they basically use string-width outside of its main usage > > domain. > > I personally feel confused when looking at the available width > calculation in Emacs: `string-width', `string-pixel-width', > `window-text-pixel-size', `length' are all different, and sometimes in > subtle (and undocumented) ways. For me, the best way to resolve the > confusion would be more detailed docstrings that explain the > limitations. I have no better ideas. string-pixel-width and window-text-pixel-size are different varieties of the same basic primitive. Other than that, each of the functions you mentioned serve a different purpose; in particular, 'length' is entirely unrelated to the display width of a string. When each API is used for its purpose, there's no confusion and no subtleties, because each one of them does its job, and the subtleties should not matter. It's only when you want them to do some job they were not directly designed for that the subtleties become important. But your insistence on documenting all of those technicalities is not TRT: it will just make the documentation much harder to understand and use for those who do use these APIs for their advertised purposes. > 1. "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." Remnant from a very distant past; ignore it. > 2. "Tabs in STRING are always taken to occupy tab-width columns." > > "always" in the above is not accurate when buffer-display-table > replaces display. Is it considered subtlety? No, "always" disregarding the column where the TAB will be displayed. A TAB that begins on column zero will be 8 columns wide; a TAB that begins on column 5 will be only 3 columns wide. > 3. "The effect of faces and fonts used for non-Latin and other unusual > characters (such as emoji) is ignored as well" > > Is the effect of faces not ignored for Latin characters? The default face's font covers those, and if it's a fixed-pitch font, the character width stored in char-width-table is adequate. > 4. "... , as are display properties and invisible text" > > What about other properties? Like 'line-prefix. Maybe "all the text > properties are ignored"? line-prefix doesn't affect the width of the string itself. "All the text properties" is incorrect: at least 'composition' and 'invisible' aren't ignored. > 5. "For these reasons, the results are not generally reliable;" > > This sounds like "this function is not useful". I've now reworded that part.