From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Cl=c3=a9ment_Pit-Claudel?= Newsgroups: gmane.emacs.devel Subject: Re: Line height issues with display-line-number-mode Date: Wed, 8 May 2019 14:04:17 -0400 Message-ID: References: <6fd496f0-7dd5-6c0e-5121-b618e7dca831@gmail.com> <83v9ymi0as.fsf@gnu.org> <21f7bf78-ac83-b3b5-421b-8ba6983dc7e8@gmail.com> <83d0ktig51.fsf@gnu.org> <83v9ylgi6c.fsf@gnu.org> 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="218014"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 08 20:04:34 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 1hOQvi-000uW5-9p for ged-emacs-devel@m.gmane.org; Wed, 08 May 2019 20:04:34 +0200 Original-Received: from localhost ([127.0.0.1]:41236 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hOQvh-0002wI-42 for ged-emacs-devel@m.gmane.org; Wed, 08 May 2019 14:04:33 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:47747) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hOQvV-0002v0-FK for emacs-devel@gnu.org; Wed, 08 May 2019 14:04:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hOQvT-0000sA-VH for emacs-devel@gnu.org; Wed, 08 May 2019 14:04:21 -0400 Original-Received: from mail-qt1-x82b.google.com ([2607:f8b0:4864:20::82b]:41001) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hOQvT-0000rE-Q2; Wed, 08 May 2019 14:04:19 -0400 Original-Received: by mail-qt1-x82b.google.com with SMTP id c13so24281585qtn.8; Wed, 08 May 2019 11:04:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=jzD+knMxXEwLo3IjF+0lFe6nutCX34yZIgwRdZ1eUGg=; b=Uc+Ab4ezF9Fxv0GIT5quvBTNuM1XHAcTIJ4NqsPap81br/9IRWlYB+0a2ucvmxdSzp kNd//DvKI6ulancSiJXSp0wQhLqcZ2a2r6fpR1LAH/XwUemRSWthfkbtYYzPxPNQro0X ZJaEg1vhRtsd+uE/GIP1ruTqY9KdXIJm/bZbHE60DVGihE52Bp7tItrr73DcYjAO2Gnx LUCAKBfmIuaaxH7nhwvlY+zcLtzbJdmpzT5gDUlMPBG3ZEAdSraQfki6CLpqz2I8vuMu LlasrR+YCBlwAOZAOXPBxHmkXTJwVjw+AglOnYWhrA1JvO3zJOW1lmeMiKAtmtiWl5W/ rkuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=jzD+knMxXEwLo3IjF+0lFe6nutCX34yZIgwRdZ1eUGg=; b=VcEVJmewQNkV1Yus67Gn/PCSL8C1RzghAj8cqOilbqTjloVjkFOgLgV+zFQppKXHQf ScNzK9+XbQY/6aI93SkAQWNyUJPc0yDlZrQARP5Xo+NegxBuR/CNOa8tDmKbaF5eVEfL 5ISYGZXM/dO9qPI6zpBtKoUokoG62C0UM2xoWZ6YBpMQlRtfKa3xFC6fEvta/yL8f/QT 6GRbGEN1pJmB2ZqrahjE56BEWx1NY1PD80oljAzKp1INnsKg6yriKFVWnJKX68T9Ilzg 0lSlOMRgMeBxE9hB4S3qGaiUmqyRQNmInfb/z+JB+FKgPXyv+3XTzLL/NbUQf0tnLdie CNow== X-Gm-Message-State: APjAAAX5QGA+vRJXXwVoUXzmpZshLGiHzUNqJ6UUKpwFQ+DE0F74YoP1 0SzFEdON6bErUZ23ytl4KdjL/ZaN X-Google-Smtp-Source: APXvYqxa6+bfLPh78eITnu141KdxgFeJL//nUYRGuSnHrPIPlW0p8sbRZcXZ/6M1oQc7iBVa8yAfag== X-Received: by 2002:ac8:3708:: with SMTP id o8mr15211182qtb.237.1557338658459; Wed, 08 May 2019 11:04:18 -0700 (PDT) Original-Received: from [128.30.93.207] (30-93-207.dynamic.csail.mit.edu. [128.30.93.207]) by smtp.googlemail.com with ESMTPSA id n62sm8928614qkd.76.2019.05.08.11.04.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 May 2019 11:04:17 -0700 (PDT) In-Reply-To: <83v9ylgi6c.fsf@gnu.org> Content-Language: en-GB X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::82b 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:236306 Archived-At: On 2019-05-08 10:00, Eli Zaretskii wrote: >> Cc: emacs-devel@gnu.org >> From: Clément Pit-Claudel >> 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.