[Top][All Lists]

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

bug#36472: 27.0.50; Convey information by showing line numbers using dif

From: Dmitry Gutov
Subject: bug#36472: 27.0.50; Convey information by showing line numbers using different colors?
Date: Mon, 15 Jul 2019 18:16:23 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2

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

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

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.

reply via email to

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