GNU bug report logs -
#36472
27.0.50; Convey information by showing line numbers using different colors?
Previous Next
Full log
Message #35 received at 36472 <at> debbugs.gnu.org (full text, mbox):
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.
This bug report was last modified 5 years and 334 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.