[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#40856: Feature request: support arbitrary propertized strings in wra
From: |
Clément Pit-Claudel |
Subject: |
bug#40856: Feature request: support arbitrary propertized strings in wrap-prefix specifications |
Date: |
Sun, 26 Apr 2020 13:23:15 -0400 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 |
On 26/04/2020 13.07, Eli Zaretskii wrote:
>> Cc: 40856@debbugs.gnu.org
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Sun, 26 Apr 2020 12:09:31 -0400
>>
>>> wrap-prefix can have value that uses :align-to, so I don't see why
>>> you'd need to call window-text-pixel-size many times. You could call> it
>>> once, and then use the result in the subsequent values of prefix.
>>
>> True, if the prefix is the same on every line.
>> But that calculation isn't very robust to changes in font sizes, other face
>> options, and windows.
>
> I don't think I follow. :align-to accepts pixel specification, so it
> should be insensitive to font changes.
I typically want to align text relative to a prefix whose length depends on
face properties, so if I use window-text-pixel-size, I need to redo the
computation every time faces change.
>> I think that would be great; the cost should be reasonable, since 1. it only
>> applies to the part of the buffer that is being displayed and 2. it won't be
>> costlier than using the stirng being measured as the wrap prefix.
>
> I don't think your 2. is necessarily correct, because you want the
> width computed each time the prefix spec is being used to produce
> glyphs, by which time the string is old history.
>
>> IOW, if we expect that it wouldn't be too costly to use a given string as
>> the wrap-prefix, then it shouldn't be too costly to use a specified space of
>> that width as the wrap prefix.
>
> I don't think I follow the logic. You intend to use :space in the
> prefix spec, not the string. So the display engine will have to
> perform layout of the string and compute its pixel width each time it
> produces a prefix for another line. The string itself is either not
> actually displayed, or is displayed on the first line of the
> paragraph, before all the wrapped lines. It may well be that
> redisplay needs to produce the display of just some lines, which don't
> even include the one with the string itself.
What I meant to say is that if it's cheap enough to draw this:
⟝ bbbbbbbbbbb
⟝ bbbbbbbbbbb
⟝ bbbbbbbbbbb
⟝ bbbbbbbbbbb
⟝ bbbbbbbbbbb
(where "⟝" is a wrap-prefix on all lines but the first)
… then it should be cheap enough to draw this:
⟝ bbbbbbbbbbb
bbbbbbbbbbb
bbbbbbbbbbb
bbbbbbbbbbb
bbbbbbbbbbb
where the indentation is a specified space as wide as "⟝".
Clément.