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

[Eli Zaretskii <eliz@gnu.org>]

> Cc: 36472@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 3 Jul 2019 17:19:09 +0300
> 
> 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.

There's some misunderstanding here, perhaps mine.  What I wanted to
say is that you may get a relative line-number string such as "-2",
which will probably tell you nothing about the position of that line.
IOW, a line number is not a good API design in this case, because the
display engine doesn't always know the absolute line number of each
line, whereas your function must have an unambiguous descriptor of the
line's location.

> >    . 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.

A face would be much easier to use from the display engine, I think.
I assume the face attributes can only specify colors?

> >    . 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

That's an absolute no-no for the display engine, because such changes
sooner or later leak to userland and cause adverse effects.

> >    . 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.

Ouch!  Another performance killer.

> > 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.

Redisplay should and does happen, but it tries very hard to determine
which portions of the window actually need to be redrawn.  For some
features, the answer is "the entire window", and that makes redisplay
slower.  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?

> 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.

I don't know about "allowed".  Would it be reasonable to say don't
switch buffers and/or don't select another window?  There are also
things you cannot really disallow, because the caller doesn't know
enough about what happens under the hood and doesn't control that.
For example, if the Lisp function calls vertical-motion or
posn-at-point, that invokes display routines, so the code in question
could be re-entered; but how can we tell Lisp programmers "don't call
anything that could call vertical-motion"?  And where to put such
limitations for them to be visible and discoverable enough in the
first place?

So I think imposing such limitations is impractical, and the only
reasonable thing to do whenever we call Lisp is take all the
precautions that assume the worst.  We had quite a few bugs recently
that were caused by not taking all the precautions.