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

[Dmitry Gutov]

On 02.07.2019 19:27, Eli Zaretskii wrote:

> I still have some questions:
>
>    . The argument is a line-number string.  You expect the absolute
>      line number there?  When the line-number display style is
>      'relative' or 'visual', the absolute line number might not be
>      available.

I'm not sure about the best design overall, but for the use case in 
question the line number should already be styled as necessary according 
to the display style. Maybe the styling function should be the first in 
this hook.

>    . What kind of object is the return value, and how should the
>      display engine use it?

A propertized string. With a 'face' or 'font-lock-face' property?

Although if we just make a hook that would return a face to use, that 
would work just as well for me.

>    . You seem to assume the hook will be called at point, but that is
>      not true: it will be called where the display engine is scanning
>      the buffer.  So you need that position (the beginning of line or
>      something) in the interface, or else you will need to calculate
>      the position from the line number, not a nice prospect.

Either the calling code would temporarily change point or, yes, the 
position would be passed to the hook functions. Either is fine by me.

>    . The display engine is sometimes called to scan buffer positions
>      outside of the window, so you should either detect that or be sure
>      to place your properties/overlays not only in the window.  Is that
>      a problem?

No, the overlays should be present everywhere by that point.

>    . What are the triggers for changing these properties/overlays?  Are
>      they determined once and for all, or can they change after the
>      buffer has been created and populated with the text?

Normally they are changed in after-save-hook. But there is an option 
that makes that happen on a timer.

> If some
>      changes in the buffer affect visual appearance of screen lines
>      that are otherwise unaffected by the changes, it would mean
>      disabling redisplay optimizations when this feature is used.  For
>      example, with 'relative' style, moving point to another line
>      requires to redraw all the lines in the window.

Well, I'm not a pro on the display engine, but shouldn't redisplay 
happen anyway when those overlays are added/modified?

Because right now they set fringe bitmaps using the before-string 
overlay property. And that should cause redisplay anyway.

> In general, calling Lisp from the display engine means complications
> and all kinds of silly precautions, to protect ourselves from crazy
> Lisp, so I'm still not very fond if the idea, sorry.

It's okay, I'm not too invested to the idea personally. But if the 
option were available, I'd whip up integration pretty quickly.

But on that subject, maybe it'd be fine to just document what the 
functions on the new hook are allowed and not allowed to do. And then 
see if we really have to add actual restrictions to force third-party 
code to behave.