[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#31666: Bad interaction between visual-line-mode and wrap-prefix on l

From: Clément Pit-Claudel
Subject: bug#31666: Bad interaction between visual-line-mode and wrap-prefix on long lines
Date: Fri, 8 Jun 2018 17:19:23 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

On 2018-06-08 14:32, Eli Zaretskii wrote:>> Cc: address@hidden
>> From: Clément Pit-Claudel <address@hidden>
>> Date: Fri, 8 Jun 2018 14:04:16 -0400
>> How hard would it be to introduce a no-break text property?
> The problem is not in introduction of the property, the problem is in
> implementing property look up where we decide whether to break a line
> on a whitespace character.  That look up might be costly, especially
> if, as usual, we are required to support both text and overlay
> properties.
I see, thanks.  If I understand correctly, at the moment, the check is done in 
the IT_DISPLAYING_WHITESPACE macro, and indeed that macro only checks for 
spaces and tabs.

Would it help to restrict that property to spaces and tabs, since we only break 
lines on these at the moment?  Or is the cost of accessing text properties from 
IT_DISPLAYING_WHITESPACE too high in any case?

I tried to see how often text properties were accessed after calling 
IT_DISPLAYING_WHITESPACE, but without too much success.  In one of the 4 calls, 
it seems that a subsequent call to PRODUCE_GLYPHS will check specified-space 
properties like QCalign_to.  For the other three calls, I'm not sure.  Would 
these other three calls sufer from additional property checks?

(I can see how overlay properties would further complicate matters.  Maybe we 
could restrict support to char properties, at first)


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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