unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Line height issues with display-line-number-mode
@ 2019-05-07 16:40 Clément Pit-Claudel
  2019-05-07 17:12 ` Noam Postavsky
  2019-05-07 18:31 ` Eli Zaretskii
  0 siblings, 2 replies; 36+ messages in thread
From: Clément Pit-Claudel @ 2019-05-07 16:40 UTC (permalink / raw)
  To: Emacs developers

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: Line height issues with display-line-number-mode
  2019-05-07 16:40 Line height issues with display-line-number-mode Clément Pit-Claudel
@ 2019-05-07 17:12 ` Noam Postavsky
  2019-05-07 18:36   ` Eli Zaretskii
  2019-05-07 18:31 ` Eli Zaretskii
  1 sibling, 1 reply; 36+ messages in thread
From: Noam Postavsky @ 2019-05-07 17:12 UTC (permalink / raw)
  To: Clément Pit-Claudel; +Cc: Emacs developers

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



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: Line height issues with display-line-number-mode
  2019-05-07 16:40 Line height issues with display-line-number-mode Clément Pit-Claudel
  2019-05-07 17:12 ` Noam Postavsky
@ 2019-05-07 18:31 ` Eli Zaretskii
  2019-05-07 21:08   ` Clément Pit-Claudel
  1 sibling, 1 reply; 36+ messages in thread
From: Eli Zaretskii @ 2019-05-07 18:31 UTC (permalink / raw)
  To: Clément Pit-Claudel; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: Line height issues with display-line-number-mode
  2019-05-07 17:12 ` Noam Postavsky
@ 2019-05-07 18:36   ` Eli Zaretskii
  2019-05-07 19:00     ` Eli Zaretskii
  0 siblings, 1 reply; 36+ messages in thread
From: Eli Zaretskii @ 2019-05-07 18:36 UTC (permalink / raw)
  To: Noam Postavsky; +Cc: cpitclaudel, emacs-devel

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



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: Line height issues with display-line-number-mode
  2019-05-07 18:36   ` Eli Zaretskii
@ 2019-05-07 19:00     ` Eli Zaretskii
  2019-05-07 19:09       ` Stefan Monnier
  0 siblings, 1 reply; 36+ messages in thread
From: Eli Zaretskii @ 2019-05-07 19:00 UTC (permalink / raw)
  To: npostavs, cpitclaudel; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: Line height issues with display-line-number-mode
  2019-05-07 19:00     ` Eli Zaretskii
@ 2019-05-07 19:09       ` Stefan Monnier
  2019-05-07 19:43         ` Eli Zaretskii
  2019-05-07 19:49         ` Ergus
  0 siblings, 2 replies; 36+ messages in thread
From: Stefan Monnier @ 2019-05-07 19:09 UTC (permalink / raw)
  To: emacs-devel

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




^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: Line height issues with display-line-number-mode
  2019-05-07 19:09       ` Stefan Monnier
@ 2019-05-07 19:43         ` Eli Zaretskii
  2019-05-07 20:30           ` Stefan Monnier
  2019-05-07 19:49         ` Ergus
  1 sibling, 1 reply; 36+ messages in thread
From: Eli Zaretskii @ 2019-05-07 19:43 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: Line height issues with display-line-number-mode
  2019-05-07 19:09       ` Stefan Monnier
  2019-05-07 19:43         ` Eli Zaretskii
@ 2019-05-07 19:49         ` Ergus
  2019-05-08  5:51           ` Eli Zaretskii
  1 sibling, 1 reply; 36+ messages in thread
From: Ergus @ 2019-05-07 19:49 UTC (permalink / raw)
  To: emacs-devel, Stefan Monnier

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: Line height issues with display-line-number-mode
  2019-05-07 19:43         ` Eli Zaretskii
@ 2019-05-07 20:30           ` Stefan Monnier
  2019-05-08  6:43             ` Eli Zaretskii
  0 siblings, 1 reply; 36+ messages in thread
From: Stefan Monnier @ 2019-05-07 20:30 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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



^ permalink raw reply related	[flat|nested] 36+ messages in thread

* Re: Line height issues with display-line-number-mode
  2019-05-07 18:31 ` Eli Zaretskii
@ 2019-05-07 21:08   ` Clément Pit-Claudel
  2019-05-08  7:01     ` Eli Zaretskii
  0 siblings, 1 reply; 36+ messages in thread
From: Clément Pit-Claudel @ 2019-05-07 21:08 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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.



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: Line height issues with display-line-number-mode
  2019-05-07 19:49         ` Ergus
@ 2019-05-08  5:51           ` Eli Zaretskii
  2019-05-08 13:40             ` Stefan Monnier
  0 siblings, 1 reply; 36+ messages in thread
From: Eli Zaretskii @ 2019-05-08  5:51 UTC (permalink / raw)
  To: Ergus; +Cc: monnier, emacs-devel

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



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: Line height issues with display-line-number-mode
  2019-05-07 20:30           ` Stefan Monnier
@ 2019-05-08  6:43             ` Eli Zaretskii
  2019-05-08 13:39               ` Stefan Monnier
  0 siblings, 1 reply; 36+ messages in thread
From: Eli Zaretskii @ 2019-05-08  6:43 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: Line height issues with display-line-number-mode
  2019-05-07 21:08   ` Clément Pit-Claudel
@ 2019-05-08  7:01     ` Eli Zaretskii
  2019-05-08 12:24       ` Clément Pit-Claudel
  0 siblings, 1 reply; 36+ messages in thread
From: Eli Zaretskii @ 2019-05-08  7:01 UTC (permalink / raw)
  To: Clément Pit-Claudel; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: Line height issues with display-line-number-mode
  2019-05-08  7:01     ` Eli Zaretskii
@ 2019-05-08 12:24       ` Clément Pit-Claudel
  2019-05-08 14:00         ` Eli Zaretskii
  0 siblings, 1 reply; 36+ messages in thread
From: Clément Pit-Claudel @ 2019-05-08 12:24 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: Line height issues with display-line-number-mode
  2019-05-08  6:43             ` Eli Zaretskii
@ 2019-05-08 13:39               ` Stefan Monnier
  2019-05-08 14:05                 ` Eli Zaretskii
  0 siblings, 1 reply; 36+ messages in thread
From: Stefan Monnier @ 2019-05-08 13:39 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

> 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



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: Line height issues with display-line-number-mode
  2019-05-08  5:51           ` Eli Zaretskii
@ 2019-05-08 13:40             ` Stefan Monnier
  2019-05-08 14:07               ` Eli Zaretskii
  0 siblings, 1 reply; 36+ messages in thread
From: Stefan Monnier @ 2019-05-08 13:40 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Ergus, emacs-devel

> 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



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: Line height issues with display-line-number-mode
  2019-05-08 12:24       ` Clément Pit-Claudel
@ 2019-05-08 14:00         ` Eli Zaretskii
  2019-05-08 18:04           ` Clément Pit-Claudel
  0 siblings, 1 reply; 36+ messages in thread
From: Eli Zaretskii @ 2019-05-08 14:00 UTC (permalink / raw)
  To: Clément Pit-Claudel; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: Line height issues with display-line-number-mode
  2019-05-08 13:39               ` Stefan Monnier
@ 2019-05-08 14:05                 ` Eli Zaretskii
  2019-05-08 14:13                   ` Noam Postavsky
  2019-05-08 14:17                   ` Stefan Monnier
  0 siblings, 2 replies; 36+ messages in thread
From: Eli Zaretskii @ 2019-05-08 14:05 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: Line height issues with display-line-number-mode
  2019-05-08 13:40             ` Stefan Monnier
@ 2019-05-08 14:07               ` Eli Zaretskii
  0 siblings, 0 replies; 36+ messages in thread
From: Eli Zaretskii @ 2019-05-08 14:07 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: spacibba, emacs-devel

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



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: Line height issues with display-line-number-mode
  2019-05-08 14:05                 ` Eli Zaretskii
@ 2019-05-08 14:13                   ` Noam Postavsky
  2019-05-08 15:04                     ` Stefan Monnier
  2019-05-08 14:17                   ` Stefan Monnier
  1 sibling, 1 reply; 36+ messages in thread
From: Noam Postavsky @ 2019-05-08 14:13 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Stefan Monnier, Emacs developers

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)



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: Line height issues with display-line-number-mode
  2019-05-08 14:05                 ` Eli Zaretskii
  2019-05-08 14:13                   ` Noam Postavsky
@ 2019-05-08 14:17                   ` Stefan Monnier
  2019-05-08 17:30                     ` Eli Zaretskii
  1 sibling, 1 reply; 36+ messages in thread
From: Stefan Monnier @ 2019-05-08 14:17 UTC (permalink / raw)
  To: emacs-devel

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




^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: Line height issues with display-line-number-mode
  2019-05-08 14:13                   ` Noam Postavsky
@ 2019-05-08 15:04                     ` Stefan Monnier
  2019-05-08 18:39                       ` Noam Postavsky
  0 siblings, 1 reply; 36+ messages in thread
From: Stefan Monnier @ 2019-05-08 15:04 UTC (permalink / raw)
  To: Noam Postavsky; +Cc: Eli Zaretskii, Emacs developers

> 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



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: Line height issues with display-line-number-mode
  2019-05-08 14:17                   ` Stefan Monnier
@ 2019-05-08 17:30                     ` Eli Zaretskii
  2019-05-08 17:46                       ` Stefan Monnier
  0 siblings, 1 reply; 36+ messages in thread
From: Eli Zaretskii @ 2019-05-08 17:30 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: Line height issues with display-line-number-mode
  2019-05-08 17:30                     ` Eli Zaretskii
@ 2019-05-08 17:46                       ` Stefan Monnier
  2019-05-08 18:02                         ` Eli Zaretskii
  0 siblings, 1 reply; 36+ messages in thread
From: Stefan Monnier @ 2019-05-08 17:46 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: Line height issues with display-line-number-mode
  2019-05-08 17:46                       ` Stefan Monnier
@ 2019-05-08 18:02                         ` Eli Zaretskii
  2019-05-08 18:39                           ` Stefan Monnier
  0 siblings, 1 reply; 36+ messages in thread
From: Eli Zaretskii @ 2019-05-08 18:02 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: Line height issues with display-line-number-mode
  2019-05-08 14:00         ` Eli Zaretskii
@ 2019-05-08 18:04           ` Clément Pit-Claudel
  2019-05-08 18:25             ` Eli Zaretskii
  2019-05-08 18:45             ` Stefan Monnier
  0 siblings, 2 replies; 36+ messages in thread
From: Clément Pit-Claudel @ 2019-05-08 18:04 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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.




^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: Line height issues with display-line-number-mode
  2019-05-08 18:04           ` Clément Pit-Claudel
@ 2019-05-08 18:25             ` Eli Zaretskii
  2019-05-08 18:45             ` Stefan Monnier
  1 sibling, 0 replies; 36+ messages in thread
From: Eli Zaretskii @ 2019-05-08 18:25 UTC (permalink / raw)
  To: Clément Pit-Claudel; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: Line height issues with display-line-number-mode
  2019-05-08 18:02                         ` Eli Zaretskii
@ 2019-05-08 18:39                           ` Stefan Monnier
  2019-05-08 18:48                             ` Eli Zaretskii
  0 siblings, 1 reply; 36+ messages in thread
From: Stefan Monnier @ 2019-05-08 18:39 UTC (permalink / raw)
  To: emacs-devel

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




^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: Line height issues with display-line-number-mode
  2019-05-08 15:04                     ` Stefan Monnier
@ 2019-05-08 18:39                       ` Noam Postavsky
  2019-05-08 18:54                         ` Eli Zaretskii
  0 siblings, 1 reply; 36+ messages in thread
From: Noam Postavsky @ 2019-05-08 18:39 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Eli Zaretskii, Emacs developers

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.



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: Line height issues with display-line-number-mode
  2019-05-08 18:04           ` Clément Pit-Claudel
  2019-05-08 18:25             ` Eli Zaretskii
@ 2019-05-08 18:45             ` Stefan Monnier
  1 sibling, 0 replies; 36+ messages in thread
From: Stefan Monnier @ 2019-05-08 18:45 UTC (permalink / raw)
  To: emacs-devel

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




^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: Line height issues with display-line-number-mode
  2019-05-08 18:39                           ` Stefan Monnier
@ 2019-05-08 18:48                             ` Eli Zaretskii
  2019-05-08 19:03                               ` Stefan Monnier
  0 siblings, 1 reply; 36+ messages in thread
From: Eli Zaretskii @ 2019-05-08 18:48 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: Line height issues with display-line-number-mode
  2019-05-08 18:39                       ` Noam Postavsky
@ 2019-05-08 18:54                         ` Eli Zaretskii
  2019-05-10  6:15                           ` Kévin Le Gouguec
  0 siblings, 1 reply; 36+ messages in thread
From: Eli Zaretskii @ 2019-05-08 18:54 UTC (permalink / raw)
  To: Noam Postavsky; +Cc: monnier, emacs-devel

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



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: Line height issues with display-line-number-mode
  2019-05-08 18:48                             ` Eli Zaretskii
@ 2019-05-08 19:03                               ` Stefan Monnier
  0 siblings, 0 replies; 36+ messages in thread
From: Stefan Monnier @ 2019-05-08 19:03 UTC (permalink / raw)
  To: emacs-devel

> 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




^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: Line height issues with display-line-number-mode
  2019-05-08 18:54                         ` Eli Zaretskii
@ 2019-05-10  6:15                           ` Kévin Le Gouguec
  2019-05-10  7:58                             ` Eli Zaretskii
  2019-05-10 13:24                             ` Stefan Monnier
  0 siblings, 2 replies; 36+ messages in thread
From: Kévin Le Gouguec @ 2019-05-10  6:15 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel, Noam Postavsky, monnier

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.



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: Line height issues with display-line-number-mode
  2019-05-10  6:15                           ` Kévin Le Gouguec
@ 2019-05-10  7:58                             ` Eli Zaretskii
  2019-05-10 13:24                             ` Stefan Monnier
  1 sibling, 0 replies; 36+ messages in thread
From: Eli Zaretskii @ 2019-05-10  7:58 UTC (permalink / raw)
  To: Kévin Le Gouguec; +Cc: emacs-devel, npostavs, monnier

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



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: Line height issues with display-line-number-mode
  2019-05-10  6:15                           ` Kévin Le Gouguec
  2019-05-10  7:58                             ` Eli Zaretskii
@ 2019-05-10 13:24                             ` Stefan Monnier
  1 sibling, 0 replies; 36+ messages in thread
From: Stefan Monnier @ 2019-05-10 13:24 UTC (permalink / raw)
  To: Kévin Le Gouguec; +Cc: Eli Zaretskii, Noam Postavsky, emacs-devel

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



^ permalink raw reply	[flat|nested] 36+ messages in thread

end of thread, other threads:[~2019-05-10 13:24 UTC | newest]

Thread overview: 36+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-05-07 16:40 Line height issues with display-line-number-mode Clément Pit-Claudel
2019-05-07 17:12 ` Noam Postavsky
2019-05-07 18:36   ` Eli Zaretskii
2019-05-07 19:00     ` Eli Zaretskii
2019-05-07 19:09       ` Stefan Monnier
2019-05-07 19:43         ` Eli Zaretskii
2019-05-07 20:30           ` Stefan Monnier
2019-05-08  6:43             ` Eli Zaretskii
2019-05-08 13:39               ` Stefan Monnier
2019-05-08 14:05                 ` Eli Zaretskii
2019-05-08 14:13                   ` Noam Postavsky
2019-05-08 15:04                     ` Stefan Monnier
2019-05-08 18:39                       ` Noam Postavsky
2019-05-08 18:54                         ` Eli Zaretskii
2019-05-10  6:15                           ` Kévin Le Gouguec
2019-05-10  7:58                             ` Eli Zaretskii
2019-05-10 13:24                             ` Stefan Monnier
2019-05-08 14:17                   ` Stefan Monnier
2019-05-08 17:30                     ` Eli Zaretskii
2019-05-08 17:46                       ` Stefan Monnier
2019-05-08 18:02                         ` Eli Zaretskii
2019-05-08 18:39                           ` Stefan Monnier
2019-05-08 18:48                             ` Eli Zaretskii
2019-05-08 19:03                               ` Stefan Monnier
2019-05-07 19:49         ` Ergus
2019-05-08  5:51           ` Eli Zaretskii
2019-05-08 13:40             ` Stefan Monnier
2019-05-08 14:07               ` Eli Zaretskii
2019-05-07 18:31 ` Eli Zaretskii
2019-05-07 21:08   ` Clément Pit-Claudel
2019-05-08  7:01     ` Eli Zaretskii
2019-05-08 12:24       ` Clément Pit-Claudel
2019-05-08 14:00         ` Eli Zaretskii
2019-05-08 18:04           ` Clément Pit-Claudel
2019-05-08 18:25             ` Eli Zaretskii
2019-05-08 18:45             ` Stefan Monnier

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).