GNU bug report logs -
#36472
27.0.50; Convey information by showing line numbers using different colors?
Previous Next
Full log
View this message in rfc822 format
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.
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.