From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Line height issues with display-line-number-mode Date: Wed, 08 May 2019 10:01:30 +0300 Message-ID: <83d0ktig51.fsf@gnu.org> References: <6fd496f0-7dd5-6c0e-5121-b618e7dca831@gmail.com> <83v9ymi0as.fsf@gnu.org> <21f7bf78-ac83-b3b5-421b-8ba6983dc7e8@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="255694"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 08 09:02:22 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hOGas-0014QL-5N for ged-emacs-devel@m.gmane.org; Wed, 08 May 2019 09:02:22 +0200 Original-Received: from localhost ([127.0.0.1]:60615 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hOGar-00042B-0R for ged-emacs-devel@m.gmane.org; Wed, 08 May 2019 03:02:21 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:48062) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hOGaG-00041y-2j for emacs-devel@gnu.org; Wed, 08 May 2019 03:01:45 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:45993) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hOGaF-0007e2-Vi; Wed, 08 May 2019 03:01:44 -0400 Original-Received: from [176.228.60.248] (port=1661 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hOGaF-00082c-1d; Wed, 08 May 2019 03:01:43 -0400 In-reply-to: <21f7bf78-ac83-b3b5-421b-8ba6983dc7e8@gmail.com> (message from =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel on Tue, 7 May 2019 17:08:24 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:236275 Archived-At: > Cc: emacs-devel@gnu.org > From: Clément Pit-Claudel > 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.