Line height issues with display-line-number-mode

Line height issues with display-line-number-mode

[Clément Pit-Claudel]

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

Hi all,

I have a package (quick-peek) that writes code like the following to display thin lines:

(with-current-buffer (get-buffer-create "*test*")
  (insert "test\ntest\ntest")
  (let ((ov (make-overlay 1 6))
        (str (propertize "\n" 'face '(:height 1 :background "#edd400"))))
    (overlay-put ov 'after-string str))
  (pop-to-buffer (current-buffer)))

With display-line-numbers-mode, however, the thin line to be a full character tall.  I have attached screenshots.

Is there a workaround for this issue?

More generally, is there a way to prevent line numbers from affecting the height of the corresponding line?  For example in compact-docstrings I shrink blank lines in documentation strings to half their usual height, but enabling display-line-numbers-mode stretches those lines back to regular height.

Thanks,
Clément.

[-- Attachment #2: no-line-numbers.png --]
[-- Type: image/png, Size: 7163 bytes --]

[-- Attachment #3: with-line-numbers.png --]
[-- Type: image/png, Size: 8338 bytes --]

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

[Noam Postavsky]

On Tue, 7 May 2019 at 12:54, Clément Pit-Claudel <cpitclaudel@gmail.com> wrote:

>         (str (propertize "\n" 'face '(:height 1 :background "#edd400"))))
>     (overlay-put ov 'after-string str))

> With display-line-numbers-mode, however, the thin line to be a full character tall.  I have attached screenshots.

describe-symbol uses a similar trick (though without indirection
through an overlay), and has the same problem.

emacs -Q
M-x global-display-line-numbers-mode RET
<f1> o display-line-numbers-mode RET

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

[Eli Zaretskii]

> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Tue, 7 May 2019 12:40:02 -0400
> 
> (with-current-buffer (get-buffer-create "*test*")
>   (insert "test\ntest\ntest")
>   (let ((ov (make-overlay 1 6))
>         (str (propertize "\n" 'face '(:height 1 :background "#edd400"))))
>     (overlay-put ov 'after-string str))
>   (pop-to-buffer (current-buffer)))
> 
> With display-line-numbers-mode, however, the thin line to be a full character tall.  I have attached screenshots.
> 
> Is there a workaround for this issue?

Only if you customize the line-number face to be smaller.

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.

> More generally, is there a way to prevent line numbers from affecting the height of the corresponding line?  For example in compact-docstrings I shrink blank lines in documentation strings to half their usual height, but enabling display-line-numbers-mode stretches those lines back to regular height.

As expected.  Make your line-number face half-height in those cases,
and you can have what you want.

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

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Date: Tue, 7 May 2019 13:12:06 -0400
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> describe-symbol uses a similar trick (though without indirection
> through an overlay), and has the same problem.

If you a re thinking about clipping characters on display in some way,
then we don't have such capabilities, AFAIK, and to introduce that
we'd have to find a way to tell Emacs which characters should be
clipped and which should affect the line height.  Ideas (let alone
patches) are welcome.

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

[Eli Zaretskii]

> Date: Tue, 07 May 2019 21:36:19 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: cpitclaudel@gmail.com, emacs-devel@gnu.org
> 
> If you a re thinking about clipping characters on display in some way,

Or maybe we could have an option not to put a number on a screen line
that starts with a display or overlay string.

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

[Stefan Monnier]

>> If you a re thinking about clipping characters on display in some way,
> Or maybe we could have an option not to put a number on a screen line
> that starts with a display or overlay string.

Not sure what would be the ideal behavior for compact-docstrings (no
line-number?  Truncated line-number?  smaller line-number?), but for
those "text lines turned into thin graphical lines" as in
describe-symbol, *vc-log*, and friends, I think the better behavior
would be to not display a line number at all.

Rather than try and guess it based on the presence of a display/overlay,
maybe we could require a specific text-property like `no-line-number`?


        Stefan
        

BTW: in nlinum-mode (and presumably linum-mode as well), the
     line-numbers are clipped, so I guess this is a difference between
     text-in-the-margin and text-in-the-"main"-area.

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Tue, 07 May 2019 15:09:23 -0400
> 
> Rather than try and guess it based on the presence of a display/overlay,
> maybe we could require a specific text-property like `no-line-number`?

We already have such a text property (display-line-number-disable),
but it cannot help here, because you do want the line of buffer text
that follows the after-string to have a number.  Only the after-string
should not have a number.

> BTW: in nlinum-mode (and presumably linum-mode as well), the
>      line-numbers are clipped, so I guess this is a difference between
>      text-in-the-margin and text-in-the-"main"-area.

Those modes didn't pay attention to overlays at all.

Anyway, people are welcome to work on some tweak in these cases.  It's
a bit tricky, because the display engine only ever looks at a single
screen line, but maybe someone will have a clever idea.

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

[Ergus]

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

If you go for this solution then, please tell it here if you push the patch, to check if we don't have the same issue with the fill-column-indicator.

On May 7, 2019 9:09:23 PM GMT+02:00, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>> If you a re thinking about clipping characters on display in some
>way,
>> Or maybe we could have an option not to put a number on a screen line
>> that starts with a display or overlay string.
>
>Not sure what would be the ideal behavior for compact-docstrings (no
>line-number?  Truncated line-number?  smaller line-number?), but for
>those "text lines turned into thin graphical lines" as in
>describe-symbol, *vc-log*, and friends, I think the better behavior
>would be to not display a line number at all.
>
>Rather than try and guess it based on the presence of a
>display/overlay,
>maybe we could require a specific text-property like `no-line-number`?
>
>
>        Stefan
>        
>
>BTW: in nlinum-mode (and presumably linum-mode as well), the
>     line-numbers are clipped, so I guess this is a difference between
>     text-in-the-margin and text-in-the-"main"-area.

-- 
Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi brevedad.

[-- Attachment #2: Type: text/html, Size: 1767 bytes --]

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

[Stefan Monnier]

>> Rather than try and guess it based on the presence of a display/overlay,
>> maybe we could require a specific text-property like `no-line-number`?
>
> 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.  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).


        Stefan


diff --git a/lisp/vc/log-edit.el b/lisp/vc/log-edit.el
index 1ae219eed5..1cf58b994c 100644
--- a/lisp/vc/log-edit.el
+++ b/lisp/vc/log-edit.el
@@ -383,7 +383,8 @@ log-edit-font-lock-keywords
          nil lax))
      ("^\n"
       (progn (goto-char (match-end 0)) (1+ (match-end 0))) nil
-      (0 '(:height 0.1 :inverse-video t))))
+      (0 '(face (:height 0.1 :inverse-video t)
+           display-line-numbers-disable t rear-nonsticky t))))
     (log-edit--match-first-line (0 'log-edit-summary))))
 
 (defvar log-edit-font-lock-gnu-style nil
@@ -487,6 +488,9 @@ log-edit-mode
 \\{log-edit-mode-map}"
   (set (make-local-variable 'font-lock-defaults)
        '(log-edit-font-lock-keywords t))
+  (make-local-variable 'font-lock-extra-managed-props)
+  (cl-pushnew 'rear-nonsticky font-lock-extra-managed-props)
+  (cl-pushnew 'display-line-numbers-disable font-lock-extra-managed-props)
   (setq-local jit-lock-contextually t)  ;For the "first line is summary".
   (make-local-variable 'log-edit-comment-ring-index)
   (add-hook 'kill-buffer-hook 'log-edit-remember-comment nil t)

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

[Clément Pit-Claudel]

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.  That is, instead of this:

1 test
2 <thick yellow line>
  test
3 test

… I'd rather see this:

1 test
  <thin yellow line>
2 test
3 test

Clément.

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

[Eli Zaretskii]

> Date: Tue, 07 May 2019 21:49:30 +0200
> From: Ergus <spacibba@aol.com>
> 
> If you go for this solution then, please tell it here if you push the patch, to check if we don't have the same
> issue with the fill-column-indicator.

The fill-column indicator is not displayed in lines that extend poast
the fill-column, so this problem doesn't happen there, or at least not
in the popular scenarios (including both scenarios described in this
thread).

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: emacs-devel@gnu.org
> 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.

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

[Eli Zaretskii]

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

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

To keep the logic simple (and thus the implementation fast and the
results predictable), we'd need some unequivocal indication that a
line number shouldn't be produced.  The question is: what would be
that indication?  Thus my questions above.

Also note that not producing a line number is not exactly what you
want: you want to see a blank line-number field of the height that is
not larger than the largest display element on the screen line.  See
my response to Stefan why this is somewhat tricky as well.

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.

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

[Clément Pit-Claudel]

[-- 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 --]

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

[Stefan Monnier]

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

Not sure what "producing an underline" means concretely.  All I tried to
do in *vc-log* (aka log-edit-mode) is to represent the separation
between the header and the body in a "graphical" (as opposed to purely
textual) way.  The current implementation is just something that works,
but we could of course change it.

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

Smaller than what?  AFAICT they wouldn't appear any smaller than when
line-numbers are turned off, or would they?


        Stefan

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

[Stefan Monnier]

> The fill-column indicator is not displayed in lines that extend poast
> the fill-column, so this problem doesn't happen there, or at least not
> in the popular scenarios (including both scenarios described in this
> thread).

At least for the *vc-log* case, the thin-separator-line is actually an
empty line, so I think the fill-column indicator might interfere in the
same way as line-numbers (I haven't checked).


        Stefan

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

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Wed, 8 May 2019 08:24:53 -0400
> 
> > "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.

That's harder than "starts with an overlay string", but still doable,
I think.  However, I wonder whether it will cover enough use cases.

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

Using an image comes to mind.  Did you consider that?

Another alternative is an empty line with the underline face.  If you
want it to fit to window dynamically, you can use the :space display
property with :align-to property.

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

What is the purpose of changing the line height in these cases?

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

On the margin it just happens to work "by sheer luck", because we
simply don't care enough about the text displayed on the margins, and
so don't take it into consideration when computing the line metrics.

The problems with doing the same in the text area I already described
in another message.  They are not insurmountable, but "Someone" should
examine all those corner cases and make sure we behave reasonably with
such a change.

> - Shrink the font?  Could line numbers be set to the same face as the line feed on their line?

Maybe with some effort, but wouldn't having smaller numbers on some
lines look ugly?  It will cause the text to begin more to the left,
although for empty lines this might not matter, if they use the
default background.

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

You'd also need to manually indent the line with some overlay string,
to have it lined up with those that do have line numbers, but other
than that, yes, it should work.

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: emacs-devel@gnu.org
> Date: Wed, 08 May 2019 09:39:58 -0400
> 
> > Btw, any reasons (other than "because we can") why we use these
> > tricks, instead of actually producing an underline?
> 
> Not sure what "producing an underline" means concretely.

Using the 'underline' face, obviously.

> > 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,
> 
> Smaller than what?

Smaller than other lines.

> AFAICT they wouldn't appear any smaller than when line-numbers are
> turned off, or would they?

They might, I'm not sure.

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

[Eli Zaretskii]

> X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_40,RCVD_IN_DNSWL_MED
> 	autolearn=disabled version=3.3.2
> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: Ergus <spacibba@aol.com>, emacs-devel@gnu.org
> Date: Wed, 08 May 2019 09:40:22 -0400
> 
> > The fill-column indicator is not displayed in lines that extend poast
> > the fill-column, so this problem doesn't happen there, or at least not
> > in the popular scenarios (including both scenarios described in this
> > thread).
> 
> At least for the *vc-log* case, the thin-separator-line is actually an
> empty line

This is a misunderstanding of what "extend" means, in this context.
It means we have glyphs there.  And we must, when the background is
not the default one.

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

[Noam Postavsky]

On Wed, 8 May 2019 at 10:06, Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> > Cc: emacs-devel@gnu.org
> > Date: Wed, 08 May 2019 09:39:58 -0400
> >
> > > Btw, any reasons (other than "because we can") why we use these
> > > tricks, instead of actually producing an underline?
> >
> > Not sure what "producing an underline" means concretely.
>
> Using the 'underline' face, obviously.

We tried this in magit, getting the line to extend to the edge of the
window is not so obvious. But we did get something working in the end.
Here it is as a patch against describe-symbol:

--- i/lisp/help-fns.el
+++ w/lisp/help-fns.el
@@ -1257,7 +1257,17 @@ describe-symbol
                            (progn (skip-chars-backward " \t\n") (point)))
             (insert "\n\n"
                     (eval-when-compile
-                      (propertize "\n" 'face '(:height 0.1 :inverse-video t)))
+                      (propertize
+                       "\n" 'face '(:underline t)
+                       'display `(space
+                                  :align-to
+                                  (+ (0 . right)
+                                     ,(min (window-hscroll)
+                                           (- (line-end-position)
+                                              (line-beginning-position)))))
+                       ;; This prevents the cursor from being rendered at the
+                       ;; edge of the window.
+                       'cursor t))
                     "\n")
             (when name
               (insert (symbol-name symbol)

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

[Stefan Monnier]

>> > Btw, any reasons (other than "because we can") why we use these
>> > tricks, instead of actually producing an underline?
>> Not sure what "producing an underline" means concretely.
> Using the 'underline' face, obviously.

I did guess this part ;-)
But what text would you apply it to?

>> > 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,
>> Smaller than what?
> Smaller than other lines.

That wouldn't be a problem but a feature: those lines are smaller than
other lines when line-numbers are not displayed, so it's not a problem
if they're also smaller when line-numbers are displayed.

>> AFAICT they wouldn't appear any smaller than when line-numbers are
>> turned off, or would they?
> They might, I'm not sure.

If it makes them smaller than without line-numbers, then it's indeed
a problem, but I wonder why/when that would happen.


        Stefan

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

[Stefan Monnier]

> We tried this in magit, getting the line to extend to the edge of the
> window is not so obvious. But we did get something working in the end.
> Here it is as a patch against describe-symbol:
>
> --- i/lisp/help-fns.el
> +++ w/lisp/help-fns.el
> @@ -1257,7 +1257,17 @@ describe-symbol
>                             (progn (skip-chars-backward " \t\n") (point)))
>              (insert "\n\n"
>                      (eval-when-compile
> -                      (propertize "\n" 'face '(:height 0.1 :inverse-video t)))
> +                      (propertize
> +                       "\n" 'face '(:underline t)
> +                       'display `(space
> +                                  :align-to
> +                                  (+ (0 . right)
> +                                     ,(min (window-hscroll)
> +                                           (- (line-end-position)
> +                                              (line-beginning-position)))))
> +                       ;; This prevents the cursor from being rendered at the
> +                       ;; edge of the window.
> +                       'cursor t))

That align-to computation looks brittle (and still incorrect, I think)
and it hardcodes into the text-property a value which can change later
(window-hscroll), so it's rather problematic.

Also, in the case of *vc-log* this would basically turn the "0.1" thick
black line into a thinner black line with a thicker "white" line above,
and that white line looks a bit odd there.  I guess strike-through would
look a bit better.

So, I'm not sure it's a good alternative (both in terms of code and in
terms of aesthetics) for log-edit-mode.


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 08 May 2019 10:17:38 -0400
> 
> >> > Btw, any reasons (other than "because we can") why we use these
> >> > tricks, instead of actually producing an underline?
> >> Not sure what "producing an underline" means concretely.
> > Using the 'underline' face, obviously.
> 
> I did guess this part ;-)
> But what text would you apply it to?

See Noam's proposal, for example.

> >> AFAICT they wouldn't appear any smaller than when line-numbers are
> >> turned off, or would they?
> > They might, I'm not sure.
> 
> If it makes them smaller than without line-numbers, then it's indeed
> a problem, but I wonder why/when that would happen.

There are too many use cases related to display, I simply cannot be
sure I remember (or even know) all of them.  Maybe you are right, and
I'm haunted by a problem that doesn't exist.

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

[Stefan Monnier]

>> If it makes them smaller than without line-numbers, then it's indeed
>> a problem, but I wonder why/when that would happen.
> There are too many use cases related to display, I simply cannot be
> sure I remember (or even know) all of them.

I know the feeling.

> Maybe you are right, and I'm haunted by a problem that doesn't exist.

If it's easy to implement, we could just try it:
Even if it turns out to make some cases worse, we do know it will
make some cases better, so there's a good chance that it's
a win overall.


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Wed, 08 May 2019 13:46:18 -0400
> 
> If it's easy to implement, we could just try it:

Implement what?  The line-height calculation was just one aspect of
the issue; the other aspects are still not clear: when to avoid
displaying a number, how to display numbers on the line people want it
to be, etc.

If we just implement the height part, all it will do in the use case
that started this thread, for example, will be display a one-pixel
"number" on the screen line that shows the yellow line, and no number
at all on the text line which follows it.  IOW, you will see
line-numbers 1 and 3, and no number 2.  Which is trading one display
glitch for another, right?

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

[Clément Pit-Claudel]

On 2019-05-08 10:00, Eli Zaretskii wrote:
>> Cc: emacs-devel@gnu.org
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Wed, 8 May 2019 08:24:53 -0400
>>
>>> "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.
> 
> That's harder than "starts with an overlay string", but still doable,
> I think.  However, I wonder whether it will cover enough use cases.

I wonder too.

>>> 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.
> 
> Using an image comes to mind.  Did you consider that?

No, I did not.  I'm not entirely sure how it would work, so I'll read about it.

> Another alternative is an empty line with the underline face.  If you
> want it to fit to window dynamically, you can use the :space display
> property with :align-to property.

Ah, interesting! I tried the following:

(with-current-buffer (get-buffer-create "*test*")
  (insert "test\ntest\ntest")
  (let ((ov (make-overlay 1 6))
        (str (concat (propertize " " 'display '(space :height (1) :align-to right) 'face '(:underline t))
		     "AAA\n"
		     "BBB"
		     (propertize " " 'display '(space :height (1) :align-to right) 'face '(:underline t)))))
    (overlay-put ov 'after-string str)
    (overlay-put ov 'face '(:underline t)))
  (pop-to-buffer (current-buffer)))

It works OK!  But it has a few problems:

* The underline is thicker under the first 'test' than under the rest of the line.  It seems to work better if I don't put the :underline property on the overlay itself… but then I don't understand why 'test' gets underlined at all.
* I need to override the underline that might be present on "BBB"
* There's a line continuation indicator after each long line.  Maybe with a more clever :align-to spec?

>> 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.
> 
> What is the purpose of changing the line height in these cases?

In compact-docstring mode, the idea is to pack more lines on the screen (the package was inspired by an idea of Stefan; see https://lists.gnu.org/archive/html/emacs-devel/2016-05/msg00401.html)

In quick-peek, it's mostly for aesthetics, to add a small amount of space between the line and the text above and below it.

>> - 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?).
> 
> On the margin it just happens to work "by sheer luck", because we
> simply don't care enough about the text displayed on the margins, and
> so don't take it into consideration when computing the line metrics.
> 
> The problems with doing the same in the text area I already described
> in another message.  They are not insurmountable, but "Someone" should
> examine all those corner cases and make sure we behave reasonably with
> such a change.

Thanks for the explanation.


>> - Shrink the font?  Could line numbers be set to the same face as the line feed on their line?
> 
> Maybe with some effort, but wouldn't having smaller numbers on some
> lines look ugly?  It will cause the text to begin more to the left,
> although for empty lines this might not matter, if they use the
> default background.

You're right; this won't work. And it would be especially bad for taller lines (if we enlarged the line number face for these).

>> 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.
> 
> You'd also need to manually indent the line with some overlay string,
> to have it lined up with those that do have line numbers, but other
> than that, yes, it should work.

Thanks. I will try it.

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

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Wed, 8 May 2019 14:04:17 -0400
> 
> (with-current-buffer (get-buffer-create "*test*")
>   (insert "test\ntest\ntest")
>   (let ((ov (make-overlay 1 6))
>         (str (concat (propertize " " 'display '(space :height (1) :align-to right) 'face '(:underline t))
> 		     "AAA\n"
> 		     "BBB"
> 		     (propertize " " 'display '(space :height (1) :align-to right) 'face '(:underline t)))))
>     (overlay-put ov 'after-string str)
>     (overlay-put ov 'face '(:underline t)))
>   (pop-to-buffer (current-buffer)))
> 
> It works OK!  But it has a few problems:
> 
> * The underline is thicker under the first 'test' than under the rest of the line.  It seems to work better if I don't put the :underline property on the overlay itself… but then I don't understand why 'test' gets underlined at all.

You have "test" underlined because your overlay covers it.  Try the
variant below instead.

> * I need to override the underline that might be present on "BBB"
> * There's a line continuation indicator after each long line.  Maybe with a more clever :align-to spec?

Probably.

(with-current-buffer (get-buffer-create "*test*")
  (insert "test\ntest\ntest")
  (let ((ov (make-overlay 6 7))
        (str (concat (propertize " " 'display '(space :height (1) :align-to right) 'face '(:underline t))
		     "AAA\n"
		     "BBB"
		     (propertize " " 'display '(space :height (1) :align-to right) 'face '(:underline t)))))
    (overlay-put ov 'before-string str)
    (overlay-put ov 'face '(:underline t)))
  (pop-to-buffer (current-buffer)))

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

[Stefan Monnier]

>> If it's easy to implement, we could just try it:
> Implement what?

"Count the line-number's height as being 1 pixel".

> If we just implement the height part, all it will do in the use case
> that started this thread, for example, will be display a one-pixel
> "number" on the screen line that shows the yellow line, and no number
> at all on the text line which follows it.  IOW, you will see
> line-numbers 1 and 3, and no number 2.  Which is trading one display
> glitch for another, right?

It won't fix that case indeed.  But it will improve the cases of
*vc-log*, describe-symbol, and compact-strings.


        Stefan

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

[Noam Postavsky]

On Wed, 8 May 2019 at 11:04, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> > --- i/lisp/help-fns.el
> > +++ w/lisp/help-fns.el
> > @@ -1257,7 +1257,17 @@ describe-symbol
> >                             (progn (skip-chars-backward " \t\n") (point)))
> >              (insert "\n\n"
> >                      (eval-when-compile
> > -                      (propertize "\n" 'face '(:height 0.1 :inverse-video t)))
> > +                      (propertize
> > +                       "\n" 'face '(:underline t)
> > +                       'display `(space
> > +                                  :align-to
> > +                                  (+ (0 . right)
> > +                                     ,(min (window-hscroll)
> > +                                           (- (line-end-position)
> > +                                              (line-beginning-position)))))
> > +                       ;; This prevents the cursor from being rendered at the
> > +                       ;; edge of the window.
> > +                       'cursor t))
>
> That align-to computation looks brittle (and still incorrect, I think)
> and it hardcodes into the text-property a value which can change later
> (window-hscroll), so it's rather problematic.

Yes, in magit this is recomputed from
redisplay-highlight-region-function, which keeps the value up to date,
but has it's own problems (e.g., inf looping in redisplay Bug#24633,
this is what `min' works around). I guess for *Help* buffers there's
not much use in hscrolling, so using just '(space :align-to right)
would be fine.

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

[Stefan Monnier]

>>>> "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.
>> That's harder than "starts with an overlay string", but still doable,
>> I think.  However, I wonder whether it will cover enough use cases.
> I wonder too.

I can also imagine cases where the line whose entire contents come from
an overlay string should be the one that gets the line-number (maybe
the two cases can be distinguished by checking where the `cursor`
property wants the display to put the cursor when point is at BOL?).


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 08 May 2019 14:39:31 -0400
> 
> > If we just implement the height part, all it will do in the use case
> > that started this thread, for example, will be display a one-pixel
> > "number" on the screen line that shows the yellow line, and no number
> > at all on the text line which follows it.  IOW, you will see
> > line-numbers 1 and 3, and no number 2.  Which is trading one display
> > glitch for another, right?
> 
> It won't fix that case indeed.  But it will improve the cases of
> *vc-log*, describe-symbol, and compact-strings.

Will it?  the line numbers on those lines will be "squashed" as well,
right?

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

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Date: Wed, 8 May 2019 14:39:42 -0400
> Cc: Eli Zaretskii <eliz@gnu.org>, Emacs developers <emacs-devel@gnu.org>
> 
> > That align-to computation looks brittle (and still incorrect, I think)
> > and it hardcodes into the text-property a value which can change later
> > (window-hscroll), so it's rather problematic.
> 
> Yes, in magit this is recomputed from
> redisplay-highlight-region-function, which keeps the value up to date,
> but has it's own problems (e.g., inf looping in redisplay Bug#24633,
> this is what `min' works around). I guess for *Help* buffers there's
> not much use in hscrolling, so using just '(space :align-to right)
> would be fine.

Maybe we should simply add a feature that would allow display of a
thin line across the window.  Then all of the problems we discussed
will just go away.

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

[Stefan Monnier]

> Will it?  the line numbers on those lines will be "squashed" as well,
> right?

Right, just like they are in linum-mode and nlinum-mode, and noone has
been bothered by it so far: I think it's much better than the current
behavior of "blowing up" the line to full-height.  And I can't think of
a behavior that's clearly better for those use cases (some users may
prefer making the number smaller or removing it altogether, but it's not
clearly better in general). 
IOW, I think it would be a better default behavior.


        Stefan

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

[Kévin Le Gouguec]

Eli Zaretskii <eliz@gnu.org> writes:

> Maybe we should simply add a feature that would allow display of a
> thin line across the window.  Then all of the problems we discussed
> will just go away.

There does seem to several use-cases for this feature (in addition to
Clément's), where it is emulated in various ways each, having its own
deficiencies.

I don't think I saw a post in this thread cataloguing all of these
methods (though most of them have been mentioned), so for the record, if
it helps anyone:

- describe-symbol

    (insert "\n\n"
            (eval-when-compile
              (propertize "\n" 'face '(:height 0.1 :inverse-video t)))
            "\n")

- custom-group-value-create

    ;; Draw a horizontal line (this works for both graphical
    ;; and text displays):
    (let ((p (point)))
      (insert "\n")
      (put-text-property p (1+ p) 'face '(:underline t))
      (overlay-put (make-overlay p (1+ p))
                   'before-string
                   (propertize "\n" 'face '(:underline t)
                               'display '(space :align-to 999))))

- log-edit-font-lock-keywords

    (0 '(:height 0.1 :inverse-video t))

On MELPA:

- magit-blame--format-separator
  https://github.com/magit/magit/blob/master/lisp/magit-blame.el

    (concat (propertize "\s" 'display '(space :height (2)))
            (propertize "\n" 'line-height t))

- transient--show
  https://github.com/magit/transient/blob/master/lisp/transient.el

    (insert (propertize "__" 'face 'transient-separator
                        'display '(space :height (1))))
    (insert (propertize "\n" 'face 'transient-separator 'line-height t)))

- page-break-lines.el
  https://github.com/purcell/page-break-lines/blob/master/page-break-lines.el

    (let ((default-height (face-attribute 'default :height nil 'default)))
      (set-face-attribute 'page-break-lines nil :height default-height)
      (let* ((cwidth (char-width page-break-lines-char))
             (wwidth-pix (- (window-width nil t)
                            (if (bound-and-true-p display-line-numbers)
                                (line-number-display-width t)
                              0)))
             (width (- (/ wwidth-pix (frame-char-width) cwidth)
                       (if (display-graphic-p) 0 1)))
             (glyph (make-glyph-code page-break-lines-char 'page-break-lines))
             (new-display-entry (vconcat (make-list width glyph))))
        (unless (equal new-display-entry (elt buffer-display-table ?\^L))
          (aset buffer-display-table ?\^L new-display-entry))))

- form-feed.el
  https://github.com/wasamasa/form-feed/blob/master/form-feed.el

(The latter two are both packages for displaying ^L as thin lines; I
wasn't sure which sections of form-feed would be relevant to include.)

FWIW, page-break-lines does seem to behave correctly when
display-line-numbers is enabled; not sure how applicable its method is
in the general case.

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

[Eli Zaretskii]

> From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
> Cc: Noam Postavsky <npostavs@gmail.com>,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Fri, 10 May 2019 08:15:36 +0200
> 
> I don't think I saw a post in this thread cataloguing all of these
> methods (though most of them have been mentioned), so for the record, if
> it helps anyone:

Thanks.

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

[Stefan Monnier]

> - describe-symbol
[...]
>               (propertize "\n" 'face '(:height 0.1 :inverse-video t)))
[...]
> - log-edit-font-lock-keywords
>     (0 '(:height 0.1 :inverse-video t))

I plead guilty for using this method.  I also used it in describe-key
and mpc.el and can't promise this list is exhaustive.


        Stefan