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: Sun, 30 Jul 2023 11:45:20 +0000 Message-ID: <873515hbcf.fsf@localhost> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29854"; 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 Sun Jul 30 14:21:47 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 1qQ5Qh-0007ba-1q for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 30 Jul 2023 14:21:47 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qQ4s8-00053j-6w; Sun, 30 Jul 2023 07:46: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 1qQ4s7-00053b-6x for bug-gnu-emacs@gnu.org; Sun, 30 Jul 2023 07:46: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 1qQ4s6-0004Ck-FY for bug-gnu-emacs@gnu.org; Sun, 30 Jul 2023 07:46:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qQ4s6-0001Sc-0A for bug-gnu-emacs@gnu.org; Sun, 30 Jul 2023 07:46: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: Sun, 30 Jul 2023 11:46: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.16907175175560 (code B ref 64696); Sun, 30 Jul 2023 11:46:01 +0000 Original-Received: (at 64696) by debbugs.gnu.org; 30 Jul 2023 11:45:17 +0000 Original-Received: from localhost ([127.0.0.1]:49462 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qQ4rM-0001Rc-Lx for submit@debbugs.gnu.org; Sun, 30 Jul 2023 07:45:17 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]:39877) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qQ4rI-0001RL-TY for 64696@debbugs.gnu.org; Sun, 30 Jul 2023 07:45:15 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id E8C61240027 for <64696@debbugs.gnu.org>; Sun, 30 Jul 2023 13:45:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1690717506; bh=tEqMKWUFBUTRFgIbVW9ES5hUooNr/vm2dLW4gDp08Wo=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=WuQkdRn0nQUyrpU53t6G2C069wfW8GR94yeYPrQLv+Erh83a1/18F1tEJKieDrVRs atVrugQs6KhJBZlACfMG4ijkfMyX0Qcua6QVcHyshjRnQoMwt4NcZZeVPglSYxWAaj ejT1Bz5BG4adt5L/GMnydn4m9BWdvTo2GYVCrppAzjT/MVLJe+MHoUuMG24NiRDfRs 3fqi2yH80EwBwAL+5Na5ARVXqd1Il5NGY8c5LtwlLA2TKkbXK9rLVX/lmKy9don9WL XPVDscHKnlvenUZj5Qbgh4iD0cTP7VYJDcup1YKkketWe75f7LNUQh94J0ZVct8uLZ nc/4tXFad07kw== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RDKL91C8Qz9sCy; Sun, 30 Jul 2023 13:45:04 +0200 (CEST) In-Reply-To: <83leexlny4.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:266367 Archived-At: Eli Zaretskii writes: >> And note that the full docstring of `string-width' does not mention the >> above 2 factors. It just mentions a small subset of visual settings that >> _do not_ affect the results. Which is deceiving. > > "Deceiving" is a harsh word, please reconsider. I did not mean being harsh. Maybe confusing is a better word. > 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. Also, may you explain some parts of the `string-width' docstring? 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." What does "validity" refer to and how is it related to width? 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? 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? Or the faces and fonts are ignored completely? 4. "... , as are display properties and invisible text" What about other properties? Like 'line-prefix. Maybe "all the text properties are ignored"? 5. "For these reasons, the results are not generally reliable;" This sounds like "this function is not useful". May it be better to rewrite this as To calculate accurate text dimensions as it is displayed in current buffer, use `window-text-pixel-size'. To take into account faces and other text properties in STRING, use `string-pixel-width'. > There are no inconsistencies, not from where I stand. Each API was > written for a specific purpose and does a specific job; if your > purpose is very different, you need to describe it first, and do that > with all the details. Then we can see if we already support your > purpose or need new APIs. This is getting too far out of scope of the initial discussion. Let's focus back on `indent-to'/`current-column' and related Emacs issues. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at