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

[Dmitry Gutov]

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.