[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: |
Sat, 9 Jun 2018 08:45:17 -0400 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 |
On 2018-06-09 04:42, Eli Zaretskii wrote:
>> 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 didn't say it would be too expensive. But it will definitely be
> more expensive than it is today, which is why I'm trying to suggest
> other solutions first.
Makes sense. Thanks.
>> 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?
>
> The IT_DISPLAYING_WHITESPACE macro itself will have to lookup text
> properties at the location where it attempts to decide whether a space
> or a tab can be used as wrap point.
>
>> (I can see how overlay properties would further complicate matters. Maybe
>> we could restrict support to char properties, at first)
>
> That'd be most probably frowned upon by the community, since we
> generally handle them the same elsewhere in Emacs.
OK, that makes sense.
> Once again, the implementation shouldn't be hard, but if alternative
> solutions exist, I'd prefer not to make the display engine slower than
> it is already.
Understood.
signature.asc
Description: OpenPGP digital signature
- bug#31666: Bad interaction between visual-line-mode and wrap-prefix on long lines, (continued)