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 09:43:19 +0300 Message-ID: <83ef59igzc.fsf@gnu.org> References: <6fd496f0-7dd5-6c0e-5121-b618e7dca831@gmail.com> <83sgtqi02k.fsf@gnu.org> <83r29ahyz2.fsf@gnu.org> <83pnouhwxs.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="180883"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 08 08:43:46 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 1hOGIr-000kyK-Tw for ged-emacs-devel@m.gmane.org; Wed, 08 May 2019 08:43:46 +0200 Original-Received: from localhost ([127.0.0.1]:60451 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hOGIq-0007jZ-Ud for ged-emacs-devel@m.gmane.org; Wed, 08 May 2019 02:43:44 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:45548) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hOGIh-0007hi-3k for emacs-devel@gnu.org; Wed, 08 May 2019 02:43:36 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:45858) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hOGIg-0005dM-QJ; Wed, 08 May 2019 02:43:34 -0400 Original-Received: from [176.228.60.248] (port=4522 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hOGIe-0007Lk-OS; Wed, 08 May 2019 02:43:33 -0400 In-reply-to: (message from Stefan Monnier on Tue, 07 May 2019 16:30:55 -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:236274 Archived-At: > From: Stefan Monnier > 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.