unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: "Clément Pit-Claudel" <cpitclaudel@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: Line height issues with display-line-number-mode
Date: Wed, 08 May 2019 10:01:30 +0300	[thread overview]
Message-ID: <83d0ktig51.fsf@gnu.org> (raw)
In-Reply-To: <21f7bf78-ac83-b3b5-421b-8ba6983dc7e8@gmail.com> (message from Clément Pit-Claudel on Tue, 7 May 2019 17:08:24 -0400)

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



  reply	other threads:[~2019-05-08  7:01 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83d0ktig51.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=cpitclaudel@gmail.com \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).