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

["Clément Pit-Claudel" <cpitclaudel@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3401 bytes --]

On 2019-05-08 03:01, Eli Zaretskii wrote:
>> Cc: emacs-devel@gnu.org
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Tue, 7 May 2019 17:08:24 -0400
>>
>> On 2019-05-07 14:31, Eli Zaretskii wrote:
>>> I don't understand what do you want to see instead of a line number if
>>> its face should use a higher font.  The Emacs display is a canvas, so
>>> the height of a screen line is determined by the highest display
>>> element on that screen line.
>>
>> I'm not sure what the ideal behavior would be; for this particular case, I think the best would likely be for the number to be displayed one line below, and no number to be displayed on the yellow line.
> 
> "This particular case" being what, in technical terms?  A line that
> begins with an overlay string?  A line whose entire contents comes
> from an overlay string?  Something else?

I'm not sure; I think 'a line whose entire contents come from an overlay string' is probably right.

> We display the line number on the yellow line, because the display
> engine produces a number after seeing the first newline that comes
> from buffer text, since such a newline increases the line count.  In
> your case, that newline is after "test" on line 1.  The yellow line
> after that doesn't come from buffer text, so it doesn't increment the
> line count, which is why the next line number, "3", is produced only
> on the last "test" line.  Producing the line number on the second
> "test" line would be trickier, because we must then somehow detect the
> _last_ line of a run of screen lines whose line number is the same.
> This defeats the simple logic of the current line-number display, in
> that it would require us to look at the text of the following lines,
> something that is tricky at best (because we only know what is on the
> following line _after_ we perform layout, and layout is performed in
> the order of buffer positions, top to bottom).

That makes sense.

> And finally, the same question I asked Stefan: why are you using this
> trick instead of producing an underline with face properties?  If the
> problem is that you want to control the thickness of the underline,
> providing such a feature is much easier than tweaking line-number
> display for these cases.

I'm trying to produce a line that stretches the entire width of the window; can this be done with underlines?  Controlling the thickness of the line is not a strict requirement for me.

Additionally, I use think lines not just to draw a colored line, but also for padding around it (so quick-peek in fact displays one think blank line, one thin line with a background, and another thin blank line).  Similarly, in compact-docstrings mode, I use face properties to make certain lines less tall.  Both of these use cases break with display-line-number-modes, and for the latter I think the only solutions would be to

- Hide line numbers (but it means computing a height for the line and then comparing it to the height needed for line numbers)
- Clip them (like nlinum did; but clipping is easier in the margin than in the buffer area; is that correct?).
- Shrink the font?  Could line numbers be set to the same face as the line feed on their line?

That being said, the trickiest case is the one with overlays, since (IIUC) I can handle the compact-docstrings case by putting a property on the lines to disable line numbers manually.

Clément.

[-- Attachment #2: d-l-n-m.png --]
[-- Type: image/png, Size: 138588 bytes --]

[-- Attachment #3: nlinum.png --]
[-- Type: image/png, Size: 149561 bytes --]