bug-gnu-emacs
[Top][All Lists]
Advanced

[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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]