emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Line height issues with display-line-number-mode


From: Eli Zaretskii
Subject: Re: Line height issues with display-line-number-mode
Date: Wed, 08 May 2019 09:43:19 +0300

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden
> Date: Tue, 07 May 2019 16:30:55 -0400
> 
> > We already have such a text property (display-line-number-disable),
> > but it cannot help here,
> 
> But it *can* help for the *vc-log* case, tho it's a bit cumbersome, see
> patch below.

That's good to know, thanks.  I guess we have yet another use case for
this issue (which doesn't use overlay strings); who knows how many
more are out there?

Btw, any reasons (other than "because we can") why we use these
tricks, instead of actually producing an underline?

> Also the line then runs not just through the text but also
> through the line-number-area (I guess that's OK, but that's not the
> behavior I was expecting).

That's what this property is supposed to produce.  It was added to
help company-mode and similar features which reproduce the display of
a portion of a buffer, replacing the "normal" display of buffer text.

What you expected, I guess, was to see a blank line-number field whose
height is according to the face of the overlay string or the text
property put on the text.  Doing this would be somewhat tricky, I
think, because the display engine lays out the line numbers _before_
it lays out the rest of the screen line, so it doesn't in general have
any idea about the height of the text in that line.  We could, in
principle, tweak the height value maintained by the display iterator,
when we produce line numbers, so that we start the layout of the rest
of the line with the height of, say, 1 pixel, and let the rest of the
line's text enlarge that as needed.  But doing this naïvely would
backfire with various special cases, like empty lines, lines with
characters whose font-provided height is small, etc.: those lines will
appear smaller in height, an unpleasant effect that we would like to
avoid.  So this technique needs some augmentation at least, to take
care of those special cases.

As I said, ideas and patches are welcome.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]