GNU bug report logs - #64696
30.0.50; indent-to inherits preceding text properties, including 'invisible

Previous Next

Full log

View this message in rfc822 format

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: monnier <at> iro.umontreal.ca, 64696 <at> debbugs.gnu.org
Subject: bug#64696: 30.0.50; indent-to inherits preceding text properties, including 'invisible
Date: Sun, 30 Jul 2023 11:45:20 +0000

Eli Zaretskii <eliz <at> gnu.org> 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 <TAB> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.