From: Ihor Radchenko <yantar92@posteo.net>
To: Eli Zaretskii <eliz@gnu.org>
Cc: monnier@iro.umontreal.ca, 64696@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 [thread overview]
Message-ID: <873515hbcf.fsf@localhost> (raw)
In-Reply-To: <83leexlny4.fsf@gnu.org>
Eli Zaretskii <eliz@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>
next prev parent reply other threads:[~2023-07-30 11:45 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-18 7:58 bug#64696: 30.0.50; indent-to inherits preceding text properties, including 'invisible Ihor Radchenko
2023-07-18 11:23 ` Eli Zaretskii
2023-07-18 12:09 ` Ihor Radchenko
2023-07-18 13:10 ` Eli Zaretskii
2023-07-18 13:25 ` Ihor Radchenko
2023-07-18 16:13 ` Eli Zaretskii
2023-07-18 16:25 ` Ihor Radchenko
2023-07-18 17:08 ` Eli Zaretskii
2023-07-19 8:30 ` Ihor Radchenko
2023-07-19 13:07 ` Eli Zaretskii
2023-07-20 9:10 ` Ihor Radchenko
2023-07-21 8:32 ` Ihor Radchenko
2023-07-22 6:51 ` Eli Zaretskii
2023-07-22 7:09 ` Ihor Radchenko
2023-07-22 11:35 ` Eli Zaretskii
2023-07-22 14:10 ` Ihor Radchenko
2023-07-22 14:31 ` Eli Zaretskii
2023-07-22 6:49 ` Eli Zaretskii
2023-07-22 7:03 ` Ihor Radchenko
2023-07-22 11:22 ` Eli Zaretskii
2023-07-22 14:05 ` Ihor Radchenko
2023-07-22 14:28 ` Eli Zaretskii
2023-07-23 7:30 ` Ihor Radchenko
2023-07-23 10:05 ` Eli Zaretskii
2023-07-24 8:18 ` Ihor Radchenko
2023-07-24 13:09 ` Eli Zaretskii
2023-07-25 8:38 ` Ihor Radchenko
2023-07-25 12:37 ` Eli Zaretskii
2023-07-27 8:58 ` Ihor Radchenko
2023-07-27 9:15 ` Eli Zaretskii
2023-07-28 8:06 ` Ihor Radchenko
2023-07-28 11:52 ` Eli Zaretskii
2023-07-29 9:00 ` Ihor Radchenko
2023-07-29 10:33 ` Eli Zaretskii
2023-07-30 7:51 ` Ihor Radchenko
2023-07-30 9:59 ` Eli Zaretskii
2023-07-30 11:45 ` Ihor Radchenko [this message]
2023-07-30 17:11 ` Eli Zaretskii
2023-07-31 7:18 ` Ihor Radchenko
2023-07-31 11:49 ` Eli Zaretskii
2023-07-28 2:53 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-28 8:30 ` Ihor Radchenko
2023-07-28 12:06 ` Eli Zaretskii
2023-07-28 12:26 ` Ihor Radchenko
2023-07-28 12:48 ` Eli Zaretskii
2023-07-28 13:02 ` Ihor Radchenko
2023-07-28 14:17 ` Eli Zaretskii
2023-07-29 9:06 ` Ihor Radchenko
2023-07-22 13:32 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-18 14:15 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-18 16:20 ` Eli Zaretskii
2023-07-18 19:33 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-19 8:42 ` Ihor Radchenko
2023-07-19 13:10 ` Eli Zaretskii
2023-07-19 14:25 ` Ihor Radchenko
2023-07-19 15:09 ` Eli Zaretskii
2023-07-19 8:41 ` Ihor Radchenko
2023-07-19 13:51 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=873515hbcf.fsf@localhost \
--to=yantar92@posteo.net \
--cc=64696@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).