bug#36472: 27.0.50; Convey information by showing line numbers using different colors?

[Dmitry Gutov <dgutov@yandex.ru>]

On 08.07.2019 15:23, Eli Zaretskii wrote:

> If the face attributes make characters wider or narrower than the
> faces of other numbers, you will have unpleasant horizontal movement
> of the line's text.  Colors can never cause this.

Makes sense.

>>>> Normally they are changed in after-save-hook. But there is an option
>>>> that makes that happen on a timer.
>>>
>>> Ouch!  Another performance killer.
>>
>> That feature already exists, you know. And it updates fringe or margin
>> indicators. People seem to like it. In my limited testing, I haven't
>> observed any major slowdowns.
> 
> I meant it will be a slow-down for redisplay.

Not sure I understand you here. Redisplay would be slowed down by 
waiting for timers?

>> So is there an optimization that looks at new overlays, checks that it
>> only has a before-string with a fringe spec, and then only updates the
>> fringe?
> 
> Some of that.  We know whether the overlays changed, and we have tests
> for whether the fringe needs to be updated on a per-line basis.

If it's really making a noticeable change, maybe we could standardize on 
a text property which would indicate which colors to use for the 
display-line-numbers area. That would circumvent the whole issue of 
running Lisp in redisplay.

>>> My question was how local are the changes caused by this
>>> feature, i.e. could it happen that changes in some place in a buffer
>>> cause changes on display in remote places?
>>
>> In my case, the hook function would just look up a property on overlays
>> at bol. Thus no far-reaching changes.
> 
> What events trigger changes in that property?

Like I said, saving a buffer, or a timer firing (depending on whether a 
certain modification in enabled). Also the user can make an overlay 
outdated by typing, so the highlighting is removed right away in such 
cases (only for the closest hunk).

> Because when the display engine works on a window, it always makes
> that window's buffer the current buffer.  If some Lisp we call changes
> that, redisplay will be confused.  So we need to save and restore the
> current buffer (and sometimes also the selected frame), to avoid such
> problems.

But if any such change is temporary (e.g. using with-current-buffer), 
it's all well, right? In that case, such limitation sounds very 
reasonable to me.

> Errors signaled during redisplay are caught and only logged in
> *Messages*, because displaying them would re-enter redisplay and cause
> the same error again.  So such errors are not very visible, and could
> go undetected for a long time.  IOW, it is better to (tediously)
> protect ourselves than signal errors in such situations.

I don't know, I still think it's better for the programmer to see the 
error to be able to fix their code. Even if it's only in *Messages*. The 
accompanying simplification of error handling sounds beneficial to me as 
well.