From: Dmitry Gutov <dgutov@yandex.ru>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 36472@debbugs.gnu.org
Subject: bug#36472: 27.0.50; Convey information by showing line numbers using different colors?
Date: Mon, 15 Jul 2019 18:16:23 +0300 [thread overview]
Message-ID: <811ed2d5-c812-a813-1292-d922df1e7fa3@yandex.ru> (raw)
In-Reply-To: <83d0ik7m1e.fsf@gnu.org>
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.
prev parent reply other threads:[~2019-07-15 15:16 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-02 11:14 bug#36472: 27.0.50; Convey information by showing line numbers using different colors? Dmitry Gutov
2019-07-02 14:30 ` Eli Zaretskii
2019-07-02 15:09 ` Dmitry Gutov
2019-07-02 15:38 ` Eli Zaretskii
2019-07-02 15:49 ` Dmitry Gutov
2019-07-02 16:27 ` Eli Zaretskii
2019-07-03 14:19 ` Dmitry Gutov
2019-07-03 16:14 ` Eli Zaretskii
2019-07-07 23:46 ` Dmitry Gutov
2019-07-08 12:23 ` Eli Zaretskii
2019-07-15 15:16 ` Dmitry Gutov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=811ed2d5-c812-a813-1292-d922df1e7fa3@yandex.ru \
--to=dgutov@yandex.ru \
--cc=36472@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.