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: Sat, 29 Jul 2023 09:00:22 +0000 [thread overview]
Message-ID: <87wmyjxfbt.fsf@localhost> (raw)
In-Reply-To: <83jzukjlse.fsf@gnu.org>
Eli Zaretskii <eliz@gnu.org> writes:
>> > Of course, there is: use the 'right' position with a negative offset.
>>
>> This indeed works, but the annoying part is calculating the offset.
>
> What offset? You said "occupy as much space as possible", which means
> the offset from the right edge is zero, right?
I meant:
^some text<stretch space>some more text$
With <stretch space> adjusting its width in such a way that the whole
line occupies exactly buffer width.
Now, I have to use
^some text<:align-to `(- right-fringe ,(string-pixel-width "some more text"))>some more text$
>> The most robust way would be delegating offset calculation to the
>> redisplay of the actual line being displayed.
>
> That would require that the display engine scans the screen line
> twice. That's unacceptable, both for performance reasons and because
> it violates the basic design of how the Emacs display iteration works.
> Sorry, that won't fly.
I do not think that double scan will be needed. Just space width
calculation is to be postponed until the line is processed.
May you point me to the place in code where the line scan is performed?
> Why does Org need to take up all the available space of a window to
> begin with, btw?
To produce right-aligned text columns:
* Heading :tag1:tag2:tag3:
* Another heading :tag4:
>> One needs to use `string-pixel-width', which is not always reliable.
>
> string-pixel-width uses the display code, so if it is unreliable, so
> will be any other implementation in the display engine (barring any
> bugs). (Of course, you didn't reveal any details of this lack of
> reliability, so I don't really know what are we talking about here.)
Because `string-pixel-width' does not account for display and
fontification settings in current-buffer. For example, buffer-local
invisibility specs will be ignored; display tables will be ignored; face
remapping will be ignored.
There is also a number of edge cases when `string-pixel-width' will
straight return wrong width. For example, when string has
line-prefix/wrap-prefix text property, its width will depend on whether
string is displayed at bol or not. `string-pixel-width' will always make
it as if string is displayed at bol, thus adding line-prefix width to
the string.
>> Return width of STRING when displayed using fixed width font.
>
> That loses information (the "current buffer" part: it's important).
> Can you explain why "fixed width font" is important enough for you to
> want to see it there? After all, the function counts columns, so
> whether the font is fixed-pitch or variable-pitch shouldn't matter.
My original concern was about `string-width' not producing reliable
results when Emacs visual settings are changed. And, indeed, some
visuals that are not detailed in the docstring are taken into account.
The purpose of using `string-width' in `org-current-text-column' is to
produce reliable result for different users with different visual
settings and fonts. This is because indentation is used in Org syntax
and must not be broken if the Org file is unchanged and visual settings
are.
>> And glyphs appear to honor variable pitch font, if it is default.
>
> No, they don't. When the function finds characters that will be
> composed on display, it computes the pixel-width of the result of the
> composition, and then converts that into the units of the frame's
> default face's font. For that conversion, and for that conversion
> only, the function needs the parameter of the default face's font that
> tells us the width of its characters; if that font is variable-pitch
> (unlikely), then these parameters give only some kind of average
> width.
I am concerned exactly about this unlikely scenario.
I have seen variable pitch creating one-off errors for width in the
past.
> But again, all this access to the font parameters is only done for
> composed characters, because character composition rules can produce
> glyphs that have no corresponding codepoints, and therefore we cannot
> look them up in char-width-table.
So, it is something Org needs to ignore somehow.
Org syntax must not depend on Emacs visual settings.
--
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-29 9:00 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 [this message]
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
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wmyjxfbt.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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.