From unknown Mon Aug 18 17:53:57 2025 X-Loop: help-debbugs@gnu.org Subject: bug#43506: 26.1; line-height sometimes has no effect on the line height Resent-From: Markus Triska Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 Sep 2020 07:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 43506 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 43506@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.160050009219355 (code B ref -1); Sat, 19 Sep 2020 07:22:01 +0000 Received: (at submit) by debbugs.gnu.org; 19 Sep 2020 07:21:32 +0000 Received: from localhost ([127.0.0.1]:45565 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kJXBb-000526-Np for submit@debbugs.gnu.org; Sat, 19 Sep 2020 03:21:31 -0400 Received: from lists.gnu.org ([209.51.188.17]:57032) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kJXBa-00051x-15 for submit@debbugs.gnu.org; Sat, 19 Sep 2020 03:21:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52996) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kJXBZ-00079i-Rx for bug-gnu-emacs@gnu.org; Sat, 19 Sep 2020 03:21:29 -0400 Received: from [78.47.144.35] (port=58146 helo=metalevel.at) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kJXBY-0006xU-4i for bug-gnu-emacs@gnu.org; Sat, 19 Sep 2020 03:21:29 -0400 Received: from mt-mbpro.localdomain (localhost [127.0.0.1]) by metalevel.at (Postfix) with ESMTP id 01D6D9E759 for ; Sat, 19 Sep 2020 09:21:24 +0200 (CEST) Received: by mt-mbpro.localdomain (Postfix, from userid 501) id 0CCDA1189D6C; Sat, 19 Sep 2020 09:21:38 +0200 (CEST) From: Markus Triska Date: Sat, 19 Sep 2020 09:21:38 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Host-Lookup-Failed: Reverse DNS lookup failed for 78.47.144.35 (failed) Received-SPF: none client-ip=78.47.144.35; envelope-from=triska@metalevel.at; helo=metalevel.at X-detected-operating-system: by eggs.gnu.org: First seen = 2020/09/19 03:21:25 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) To reproduce this issue, please start Emacs with "emacs -Q" and then evaluate the following form: (progn (goto-char (point-max)) (insert "\n") (insert (propertize "\n" 'line-height 3)) (forward-line -1) (line-pixel-height)) In my case, the minibuffer then states "17". The expected result is 3, because documentation states: A newline can have a =E2=80=98line-height=E2=80=99 text or overlay p= roperty that controls the total height of the display line ending in that newline. For comparison, it works exactly as expected if I change "3" to "300" in the snippet above, yielding "300" in the minibuffer. If possible, could you please make line-height control the total height of the display line also in the original example, or alternatively consider changing the documentation to mention all relevant exceptions? Thank you and all the best! Markus In GNU Emacs 26.1 (build 1, x86_64-apple-darwin15.3.0, X toolkit, Xaw scrol= l bars) of 2018-09-22 built on mt-laptop Windowing system distributor 'The X.Org Foundation', version 11.0.11502000 From unknown Mon Aug 18 17:53:57 2025 X-Loop: help-debbugs@gnu.org Subject: bug#43506: 26.1; line-height sometimes has no effect on the line height Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 Sep 2020 08:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43506 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Markus Triska Cc: 43506@debbugs.gnu.org Received: via spool by 43506-submit@debbugs.gnu.org id=B43506.160050510427350 (code B ref 43506); Sat, 19 Sep 2020 08:46:02 +0000 Received: (at 43506) by debbugs.gnu.org; 19 Sep 2020 08:45:04 +0000 Received: from localhost ([127.0.0.1]:45626 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kJYUR-00076c-Aw for submit@debbugs.gnu.org; Sat, 19 Sep 2020 04:45:03 -0400 Received: from eggs.gnu.org ([209.51.188.92]:57914) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kJYUP-00074v-1q; Sat, 19 Sep 2020 04:45:01 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:41797) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kJYUJ-0007Nm-77; Sat, 19 Sep 2020 04:44:55 -0400 Received: from [176.228.60.248] (port=3202 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kJYUF-0007Dc-D4; Sat, 19 Sep 2020 04:44:51 -0400 Date: Sat, 19 Sep 2020 11:45:06 +0300 Message-Id: <83r1qy2m0d.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Markus Triska on Sat, 19 Sep 2020 09:21:38 +0200) References: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) tags 43506 notabug thanks > From: Markus Triska > Date: Sat, 19 Sep 2020 09:21:38 +0200 > > (progn > (goto-char (point-max)) > (insert "\n") > (insert (propertize "\n" 'line-height 3)) > (forward-line -1) > (line-pixel-height)) > > In my case, the minibuffer then states "17". The expected result is 3, > because documentation states: > > A newline can have a ‘line-height’ text or overlay property that > controls the total height of the display line ending in that newline. That's not all the documentation says about 'line-height'. It also says this (in the "Line Height" node referenced from the place you cite): There are several ways to explicitly specify a larger line height, either by specifying an absolute height for the display line, or by specifying vertical space. However, no matter what you specify, the actual line height can never be less than the default. [...] Finally, a newline can have a ‘line-spacing’ text or overlay property that can enlarge the default frame line spacing and the buffer local ‘line-spacing’ variable: if its value is larger than the buffer or frame defaults, that larger value is used instead, for the display line ending in that newline. IOW, this property can only enlarge the line's height, which is confirmed by the fact that using 300 in your example does work as expected. This is not a bug. This property exists so a Lisp program could produce higher lines than the default. To produce lower lines, you can use a face with a low :height attribute, and arrange for the newline to have that face. You can find an example of doing that in log-edit.el. > If possible, could you please make line-height control the total height > of the display line also in the original example, or alternatively > consider changing the documentation to mention all relevant exceptions? The documentation already mentions the limitations, see above. From unknown Mon Aug 18 17:53:57 2025 X-Loop: help-debbugs@gnu.org Subject: bug#43506: 26.1; line-height sometimes has no effect on the line height Resent-From: Markus Triska Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 Sep 2020 10:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43506 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug To: Eli Zaretskii Cc: 43506@debbugs.gnu.org Received: via spool by 43506-submit@debbugs.gnu.org id=B43506.160051004827258 (code B ref 43506); Sat, 19 Sep 2020 10:08:02 +0000 Received: (at 43506) by debbugs.gnu.org; 19 Sep 2020 10:07:28 +0000 Received: from localhost ([127.0.0.1]:45692 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kJZmB-00075a-N0 for submit@debbugs.gnu.org; Sat, 19 Sep 2020 06:07:27 -0400 Received: from [78.47.144.35] (port=52006 helo=metalevel.at) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kJZmA-00075R-4p for 43506@debbugs.gnu.org; Sat, 19 Sep 2020 06:07:26 -0400 Received: by metalevel.at (Postfix, from userid 1000) id D4BB89F561; Sat, 19 Sep 2020 12:07:24 +0200 (CEST) From: Markus Triska References: <83r1qy2m0d.fsf@gnu.org> Date: Sat, 19 Sep 2020 12:07:24 +0200 In-Reply-To: <83r1qy2m0d.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 19 Sep 2020 11:45:06 +0300") Message-ID: <87v9ga6pwj.fsf@metalevel.at> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Eli Zaretskii writes: > There are several ways to explicitly specify a larger line height, > either by specifying an absolute height for the display line, or by > specifying vertical space. However, no matter what you spec [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 SPF_NONE SPF: sender does not publish an SPF Record 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Eli Zaretskii writes: > There are several ways to explicitly specify a larger line height, > either by specifying an absolute height for the display line, or by > specifying vertical space. However, no matter what you specify, the > actual line height can never be less than the default. I find that this is not the case: For example, if I change "3" to "t" in the snippet I posted, then I get "0" in the minibuffer, indicating that the line height can become as low as 0 by using this property. > IOW, this property can only enlarge the line's height, which is > confirmed by the fact that using 300 in your example does work as > expected. Please see above: The property seems to be usable to get very small line heights too. However, it does not seem to work for integers. > The documentation already mentions the limitations, see above. The limitations seem not to be correctly documented at the moment. Thank you and all the best, Markus From unknown Mon Aug 18 17:53:57 2025 X-Loop: help-debbugs@gnu.org Subject: bug#43506: 26.1; line-height sometimes has no effect on the line height Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 Sep 2020 11:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43506 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug To: Markus Triska Cc: 43506@debbugs.gnu.org Received: via spool by 43506-submit@debbugs.gnu.org id=B43506.1600513580395 (code B ref 43506); Sat, 19 Sep 2020 11:07:02 +0000 Received: (at 43506) by debbugs.gnu.org; 19 Sep 2020 11:06:20 +0000 Received: from localhost ([127.0.0.1]:45740 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kJahA-00006I-6z for submit@debbugs.gnu.org; Sat, 19 Sep 2020 07:06:20 -0400 Received: from eggs.gnu.org ([209.51.188.92]:51494) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kJah7-000063-Ve for 43506@debbugs.gnu.org; Sat, 19 Sep 2020 07:06:18 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:42836) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kJah2-0005y0-7i; Sat, 19 Sep 2020 07:06:12 -0400 Received: from [176.228.60.248] (port=4896 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kJagt-00037Q-FD; Sat, 19 Sep 2020 07:06:11 -0400 Date: Sat, 19 Sep 2020 14:06:08 +0300 Message-Id: <83mu1m2fhb.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87v9ga6pwj.fsf@metalevel.at> (message from Markus Triska on Sat, 19 Sep 2020 12:07:24 +0200) References: <83r1qy2m0d.fsf@gnu.org> <87v9ga6pwj.fsf@metalevel.at> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Markus Triska > Cc: 43506@debbugs.gnu.org > Date: Sat, 19 Sep 2020 12:07:24 +0200 > > Eli Zaretskii writes: > > > There are several ways to explicitly specify a larger line height, > > either by specifying an absolute height for the display line, or by > > specifying vertical space. However, no matter what you specify, the > > actual line height can never be less than the default. > > I find that this is not the case: For example, if I change "3" to "t" in > the snippet I posted, then I get "0" in the minibuffer, indicating that > the line height can become as low as 0 by using this property. The value t is not a valid value for the line-height property. So you are invoking "unspecified behavior" here by using it. > > IOW, this property can only enlarge the line's height, which is > > confirmed by the fact that using 300 in your example does work as > > expected. > > Please see above: The property seems to be usable to get very small line > heights too. That the invalid value t produces a zero-height screen line might be a separate bug in the display engine, but AFAICT it's harmless: the cursor is displayed normally, and a zero-height screen line is useless anyway, because you cannot show anything in that line. > However, it does not seem to work for integers. As documented. > > The documentation already mentions the limitations, see above. > > The limitations seem not to be correctly documented at the moment. The limitations are documented; what happens when you use invalid values isn't (and doesn't have to be). From unknown Mon Aug 18 17:53:57 2025 X-Loop: help-debbugs@gnu.org Subject: bug#43506: 26.1; line-height sometimes has no effect on the line height Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 Sep 2020 11:44:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43506 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug To: triska@metalevel.at Cc: 43506@debbugs.gnu.org Received: via spool by 43506-submit@debbugs.gnu.org id=B43506.160051580212033 (code B ref 43506); Sat, 19 Sep 2020 11:44:01 +0000 Received: (at 43506) by debbugs.gnu.org; 19 Sep 2020 11:43:22 +0000 Received: from localhost ([127.0.0.1]:45762 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kJbH0-000381-4F for submit@debbugs.gnu.org; Sat, 19 Sep 2020 07:43:22 -0400 Received: from eggs.gnu.org ([209.51.188.92]:56904) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kJbGw-00037l-Ew for 43506@debbugs.gnu.org; Sat, 19 Sep 2020 07:43:20 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:43087) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kJbGq-0001VB-EF; Sat, 19 Sep 2020 07:43:12 -0400 Received: from [176.228.60.248] (port=3303 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kJbGp-0005F4-GV; Sat, 19 Sep 2020 07:43:12 -0400 Date: Sat, 19 Sep 2020 14:43:26 +0300 Message-Id: <83lfh62dr5.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <83mu1m2fhb.fsf@gnu.org> (message from Eli Zaretskii on Sat, 19 Sep 2020 14:06:08 +0300) References: <83r1qy2m0d.fsf@gnu.org> <87v9ga6pwj.fsf@metalevel.at> <83mu1m2fhb.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sat, 19 Sep 2020 14:06:08 +0300 > From: Eli Zaretskii > Cc: 43506@debbugs.gnu.org > > > From: Markus Triska > > Cc: 43506@debbugs.gnu.org > > Date: Sat, 19 Sep 2020 12:07:24 +0200 > > > > Eli Zaretskii writes: > > > > > There are several ways to explicitly specify a larger line height, > > > either by specifying an absolute height for the display line, or by > > > specifying vertical space. However, no matter what you specify, the > > > actual line height can never be less than the default. > > > > I find that this is not the case: For example, if I change "3" to "t" in > > the snippet I posted, then I get "0" in the minibuffer, indicating that > > the line height can become as low as 0 by using this property. > > The value t is not a valid value for the line-height property. So you > are invoking "unspecified behavior" here by using it. Sorry, my bad. The value of t _is_ valid, as documented in the ELisp manual: If the property value is ‘t’, the newline character has no effect on the displayed height of the line—the visible contents alone determine the height. The ‘line-spacing’ property, described below, is also ignored in this case. This is useful for tiling small images (or image slices) without adding blank areas between the images. This feature is indeed used in image.el, which see. So the value of t indeed can cause an empty line to appear to have a zero pixel-height, but such an empty line cannot display anything, and the cursor on that line will have its normal default height. The use case for using this value is as described above, and does not make sense for empty lines. All other values of this property cannot make the line's height smaller, as documented. The conclusion is as before: an integer value of the 'line-height' property cannot make the line's height on display smaller than the default height. From unknown Mon Aug 18 17:53:57 2025 X-Loop: help-debbugs@gnu.org Subject: bug#43506: 26.1; line-height sometimes has no effect on the line height Resent-From: Markus Triska Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 Sep 2020 11:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43506 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug To: Eli Zaretskii Cc: 43506@debbugs.gnu.org Received: via spool by 43506-submit@debbugs.gnu.org id=B43506.160051583512085 (code B ref 43506); Sat, 19 Sep 2020 11:44:02 +0000 Received: (at 43506) by debbugs.gnu.org; 19 Sep 2020 11:43:55 +0000 Received: from localhost ([127.0.0.1]:45765 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kJbHX-00038r-Fe for submit@debbugs.gnu.org; Sat, 19 Sep 2020 07:43:55 -0400 Received: from [78.47.144.35] (port=52856 helo=metalevel.at) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kJbHW-00038j-K1 for 43506@debbugs.gnu.org; Sat, 19 Sep 2020 07:43:54 -0400 Received: by metalevel.at (Postfix, from userid 1000) id 679F59F561; Sat, 19 Sep 2020 13:43:53 +0200 (CEST) From: Markus Triska References: <83r1qy2m0d.fsf@gnu.org> <87v9ga6pwj.fsf@metalevel.at> <83mu1m2fhb.fsf@gnu.org> Date: Sat, 19 Sep 2020 13:43:53 +0200 In-Reply-To: <83mu1m2fhb.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 19 Sep 2020 14:06:08 +0300") Message-ID: <87363ef0ue.fsf@metalevel.at> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Eli Zaretskii writes: > The value t is not a valid value for the line-height property. So you > are invoking "unspecified behavior" here by using it. This is very surprising to read, because the documentation itself states: Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_NONE SPF: sender does not publish an SPF Record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Eli Zaretskii writes: > The value t is not a valid value for the line-height property. So you > are invoking "unspecified behavior" here by using it. This is very surprising to read, because the documentation itself states: If the property value is =E2=80=98t=E2=80=99, the newline character= has no effect on the displayed height of the line=E2=80=94the visible contents alone det= ermine=20=20=20 the height. Is it indeed true that t is not a valid value for the line-height property? In one of my applications, I am using the t property to ensure that adding a newline does not increase the line height in any way, and I would prefer if this behaviour is retained also in future Emacs versions. > The limitations are documented; what happens when you use invalid > values isn't (and doesn't have to be). What is documented seems to contradict what I observe, and also what the documentation itself states in other places. All the best, Markus From unknown Mon Aug 18 17:53:57 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Markus Triska Subject: bug#43506: closed (Re: bug#43506: 26.1; line-height sometimes has no effect on the line height) Message-ID: References: X-Gnu-PR-Message: they-closed 43506 X-Gnu-PR-Package: emacs X-Gnu-PR-Keywords: notabug Reply-To: 43506@debbugs.gnu.org Date: Tue, 11 Feb 2025 07:23:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1739258582-9455-1" This is a multi-part message in MIME format... ------------=_1739258582-9455-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #43506: 26.1; line-height sometimes has no effect on the line height which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 43506@debbugs.gnu.org. --=20 43506: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D43506 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1739258582-9455-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 43506-done) by debbugs.gnu.org; 11 Feb 2025 07:22:57 +0000 Received: from localhost ([127.0.0.1]:53968 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1thkbg-0002S9-Uj for submit@debbugs.gnu.org; Tue, 11 Feb 2025 02:22:57 -0500 Received: from mail-ed1-x530.google.com ([2a00:1450:4864:20::530]:57782) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1thkbf-0002Rl-4Q for 43506-done@debbugs.gnu.org; Tue, 11 Feb 2025 02:22:55 -0500 Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-5de4d4adac9so7162105a12.3 for <43506-done@debbugs.gnu.org>; Mon, 10 Feb 2025 23:22:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1739258569; x=1739863369; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date :mime-version:references:in-reply-to:from:from:to:cc:subject:date :message-id:reply-to; bh=aYv7vM4r+5lW9xhPJ5nAHWvno3HxKTTh9B1RdPQKaGY=; b=AJ5ypDr4RH0dq2GZfL7XCftbVF7P07AJL16Mk/+xDVYCEZCD/PTBuE4PFFDgPc2/F8 jsR0RsyxjSboupH7ai6RAJbEQBwTuARride6z63N0Lct6biFl4bUb+3T4n5Y6qjb4djv NkOt3d1HnvBkxdzrQS/IfrBD0esSL6VBmdWRh1rYPeAcD31+1fCcpndp0myPE/z/E1ku 7EcxpTgJ2iGp577vvtz2b+ZyBywi79CDeg/aWuzKjtVQ1JmBsr6c4jUqD9Kb38GF2AZa /1S+AwlVW/ixImVo7gGmtNZJd7E5NrAOn8AwWh4fvCIR4+hO2aoJ3VYcGP13vYTpwCaT YrIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739258569; x=1739863369; h=content-transfer-encoding:cc:to:subject:message-id:date :mime-version:references:in-reply-to:from:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=aYv7vM4r+5lW9xhPJ5nAHWvno3HxKTTh9B1RdPQKaGY=; b=shw1HcTR4k+I1Ga7yRh+CWC3ezR6X+aig7kLZxzPxii8rSVuRBMsGmtvf7p10FEL9s xB92EqNEUg6vnPjL3D/6FvjX4kDQUfNdYqpaV93ZKNce0JD0LA5TbbvyyRHV9VAQNpvU nc7kwtqc1jE9Vm48H1RU5en8z7uobqLdmDHrHzReixFRLJehi75rl4b1xa1Yhg8IKIoS OWq0Y7OTs0ItZleGUJz3a8MCjcnURIFpN/i6vmUW4E+ThCuECnR8XjdyS/u67xGqLNTr Khv10rECq4kV66CpfuVBUh4tyAgVFdPWfTokrh5Et1rBFELHMYa7kAH9wNRkcijehnLw qGMw== X-Forwarded-Encrypted: i=1; AJvYcCXKQMI2NvIGtq5e32aKn2jcKzCDXIz3mPD62JN7uJ36VtBhvBOEzIDgJXNhdYz7PqldbzBUkxcFtUNR@debbugs.gnu.org X-Gm-Message-State: AOJu0Ywf7KPJv5Qnps1vVYD6ZKDMJbQUsB+Hy0EUmLzVyMm6J9TIAi7d BXmcKwpKmsmcfDta0t5cDcU0rFOl0OHcflfUPknl8gTiKiXMKUsyL3ycT8tM4ieWrrVQUu8qGuj 1DJDVTy7ulAf+gV8wAFP6/OpLCR7T1sRxzPM= X-Gm-Gg: ASbGncs+nfUoFFpZAT2wJ1kvmxAsy3NboxholMHQtWn3ke/3UqtWuKvsEoeUesUW2LI puAe86Lj/8oNaD63VjjfjwViTsLZ0HRZdvXDF3jAOFKCb2G8WkUtFN1RRwNGbNQDuz/rCPeHoTg == X-Google-Smtp-Source: AGHT+IHiFGVHqjXm1vbH+SJfQrYT400fWXVotFECBNp3jrZt1EiKvuJMF2e/YxWSu2pJzQngIPAT/PjRWoweUAaNjJc= X-Received: by 2002:a05:6402:2113:b0:5de:a74c:3dbf with SMTP id 4fb4d7f45d1cf-5dea74c4009mr96837a12.28.1739258568696; Mon, 10 Feb 2025 23:22:48 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Mon, 10 Feb 2025 23:22:47 -0800 From: Stefan Kangas In-Reply-To: <83lfh62dr5.fsf@gnu.org> References: <83r1qy2m0d.fsf@gnu.org> <87v9ga6pwj.fsf@metalevel.at> <83mu1m2fhb.fsf@gnu.org> <83lfh62dr5.fsf@gnu.org> MIME-Version: 1.0 Date: Mon, 10 Feb 2025 23:22:47 -0800 X-Gm-Features: AWEUYZkLqLbGf1WqmzsXZDU6vtoNwpPnYMbI3oertC0O7ynxU7NBrNfTJX8b1Ps Message-ID: Subject: Re: bug#43506: 26.1; line-height sometimes has no effect on the line height To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 43506-done Cc: 43506-done@debbugs.gnu.org, triska@metalevel.at X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> Date: Sat, 19 Sep 2020 14:06:08 +0300 >> From: Eli Zaretskii >> Cc: 43506@debbugs.gnu.org >> >> > From: Markus Triska >> > Cc: 43506@debbugs.gnu.org >> > Date: Sat, 19 Sep 2020 12:07:24 +0200 >> > >> > Eli Zaretskii writes: >> > >> > > There are several ways to explicitly specify a larger line heig= ht, >> > > either by specifying an absolute height for the display line, or b= y >> > > specifying vertical space. However, no matter what you specify, t= he >> > > actual line height can never be less than the default. >> > >> > I find that this is not the case: For example, if I change "3" to "t" = in >> > the snippet I posted, then I get "0" in the minibuffer, indicating tha= t >> > the line height can become as low as 0 by using this property. >> >> The value t is not a valid value for the line-height property. So you >> are invoking "unspecified behavior" here by using it. > > Sorry, my bad. The value of t _is_ valid, as documented in the ELisp > manual: > > If the property value is =E2=80=98t=E2=80=99, the newline character = has no effect on > the displayed height of the line=E2=80=94the visible contents alone det= ermine > the height. The =E2=80=98line-spacing=E2=80=99 property, described bel= ow, is also > ignored in this case. This is useful for tiling small images (or image > slices) without adding blank areas between the images. > > This feature is indeed used in image.el, which see. > > So the value of t indeed can cause an empty line to appear to have a > zero pixel-height, but such an empty line cannot display anything, and > the cursor on that line will have its normal default height. The use > case for using this value is as described above, and does not make > sense for empty lines. > > All other values of this property cannot make the line's height > smaller, as documented. > > The conclusion is as before: an integer value of the 'line-height' > property cannot make the line's height on display smaller than the > default height. No further comments within 4 years. I'm therefore closing this bug report. ------------=_1739258582-9455-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 19 Sep 2020 07:21:32 +0000 Received: from localhost ([127.0.0.1]:45565 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kJXBb-000526-Np for submit@debbugs.gnu.org; Sat, 19 Sep 2020 03:21:31 -0400 Received: from lists.gnu.org ([209.51.188.17]:57032) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kJXBa-00051x-15 for submit@debbugs.gnu.org; Sat, 19 Sep 2020 03:21:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52996) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kJXBZ-00079i-Rx for bug-gnu-emacs@gnu.org; Sat, 19 Sep 2020 03:21:29 -0400 Received: from [78.47.144.35] (port=58146 helo=metalevel.at) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kJXBY-0006xU-4i for bug-gnu-emacs@gnu.org; Sat, 19 Sep 2020 03:21:29 -0400 Received: from mt-mbpro.localdomain (localhost [127.0.0.1]) by metalevel.at (Postfix) with ESMTP id 01D6D9E759 for ; Sat, 19 Sep 2020 09:21:24 +0200 (CEST) Received: by mt-mbpro.localdomain (Postfix, from userid 501) id 0CCDA1189D6C; Sat, 19 Sep 2020 09:21:38 +0200 (CEST) From: Markus Triska To: bug-gnu-emacs@gnu.org Subject: 26.1; line-height sometimes has no effect on the line height Date: Sat, 19 Sep 2020 09:21:38 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Host-Lookup-Failed: Reverse DNS lookup failed for 78.47.144.35 (failed) Received-SPF: none client-ip=78.47.144.35; envelope-from=triska@metalevel.at; helo=metalevel.at X-detected-operating-system: by eggs.gnu.org: First seen = 2020/09/19 03:21:25 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) To reproduce this issue, please start Emacs with "emacs -Q" and then evaluate the following form: (progn (goto-char (point-max)) (insert "\n") (insert (propertize "\n" 'line-height 3)) (forward-line -1) (line-pixel-height)) In my case, the minibuffer then states "17". The expected result is 3, because documentation states: A newline can have a =E2=80=98line-height=E2=80=99 text or overlay p= roperty that controls the total height of the display line ending in that newline. For comparison, it works exactly as expected if I change "3" to "300" in the snippet above, yielding "300" in the minibuffer. If possible, could you please make line-height control the total height of the display line also in the original example, or alternatively consider changing the documentation to mention all relevant exceptions? Thank you and all the best! Markus In GNU Emacs 26.1 (build 1, x86_64-apple-darwin15.3.0, X toolkit, Xaw scrol= l bars) of 2018-09-22 built on mt-laptop Windowing system distributor 'The X.Org Foundation', version 11.0.11502000 ------------=_1739258582-9455-1-- From unknown Mon Aug 18 17:53:57 2025 X-Loop: help-debbugs@gnu.org Subject: bug#43506: 26.1; line-height sometimes has no effect on the line height Resent-From: Markus Triska Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Feb 2025 18:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43506 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug To: Stefan Kangas Cc: Eli Zaretskii , 43506-done@debbugs.gnu.org Received: via spool by 43506-done@debbugs.gnu.org id=D43506.173929706031874 (code D ref 43506); Tue, 11 Feb 2025 18:05:02 +0000 Received: (at 43506-done) by debbugs.gnu.org; 11 Feb 2025 18:04:20 +0000 Received: from localhost ([127.0.0.1]:58512 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1thucO-0008I2-2X for submit@debbugs.gnu.org; Tue, 11 Feb 2025 13:04:20 -0500 Received: from [78.47.144.35] (port=58264 helo=metalevel.at) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1thucL-0008Hr-7K for 43506-done@debbugs.gnu.org; Tue, 11 Feb 2025 13:04:17 -0500 Received: by metalevel.at (Postfix, from userid 1000) id 274569C791; Tue, 11 Feb 2025 19:04:15 +0100 (CET) From: Markus Triska References: <83r1qy2m0d.fsf@gnu.org> <87v9ga6pwj.fsf@metalevel.at> <83mu1m2fhb.fsf@gnu.org> <83lfh62dr5.fsf@gnu.org> Date: Tue, 11 Feb 2025 19:04:15 +0100 In-Reply-To: (Stefan Kangas's message of "Mon, 10 Feb 2025 23:22:47 -0800") Message-ID: <871pw4uzmo.fsf@metalevel.at> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Stefan Kangas writes: > No further comments within 4 years. > > I'm therefore closing this bug report. I understand that you, as maintainers, close an existing report if you do not consider at an issue. However, if there is any need to reconfirm an existing issue every 4 years, then please consider thi [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 RCVD_IN_VALIDITY_SAFE_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. [78.47.144.35 listed in sa-trusted.bondedsender.org] 0.0 SPF_NONE SPF: sender does not publish an SPF Record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. [78.47.144.35 listed in bl.score.senderscore.com] 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Stefan Kangas writes: > No further comments within 4 years. > > I'm therefore closing this bug report. I understand that you, as maintainers, close an existing report if you do not consider at an issue. However, if there is any need to reconfirm an existing issue every 4 years, then please consider this reply as such reconfirmation. Thank you and all the best, Markus From unknown Mon Aug 18 17:53:57 2025 X-Loop: help-debbugs@gnu.org Subject: bug#43506: 26.1; line-height sometimes has no effect on the line height Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Feb 2025 18:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43506 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug To: Markus Triska Cc: 43506@debbugs.gnu.org, Eli Zaretskii Received: via spool by 43506-submit@debbugs.gnu.org id=B43506.17392983583341 (code B ref 43506); Tue, 11 Feb 2025 18:26:02 +0000 Received: (at 43506) by debbugs.gnu.org; 11 Feb 2025 18:25:58 +0000 Received: from localhost ([127.0.0.1]:58556 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1thuxK-0000rp-0S for submit@debbugs.gnu.org; Tue, 11 Feb 2025 13:25:58 -0500 Received: from mail-ed1-x52a.google.com ([2a00:1450:4864:20::52a]:56583) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1thuxH-0000rZ-W3 for 43506@debbugs.gnu.org; Tue, 11 Feb 2025 13:25:56 -0500 Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-5de5bf41652so6041655a12.1 for <43506@debbugs.gnu.org>; Tue, 11 Feb 2025 10:25:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1739298349; x=1739903149; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=AqQPsWZdqNoN4F3YFFvb2tpalQaIgSxUMXl9pieBCoQ=; b=LolJ7ORYeo0vzFOYggyhVtcYPRGVi4ZvAxhfqnpiym9KRubQVF8gjYGPKfy6b1DTuS fRSmB7+U8u7McRwVjwv8Mh9rL/loBkHM44eXhIXZRqPqfaBOxFe37ihes3u/cPXF2LsW fBBckyPIjqC3sPxrE74pkLbABdhiWeexwO6FNXzg2kBn9lk3IgiaM5o1Axzy9uu/e8PC +A9hFv0OmCEyMdL06DphqGiXJbpJkY9jUUadMwhJd8Rb8IIx62R0jNunBNfqaBV0TB8o pJoSwNpwKnF2WoBGIoqQ58bbt1xsWYIsVQkMXN6VqJdMCe4vsNUGvz5RrzOjbtAz31Dl cKHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739298349; x=1739903149; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=AqQPsWZdqNoN4F3YFFvb2tpalQaIgSxUMXl9pieBCoQ=; b=Jp4wOFV227ZrfaHqxs7YsF936WadNq1dGhQi3CU1Q1ZDn7XJfkDL7FsAdw7I+ohF1o mawTR8yYWIZH2AsfO+ziINBJDm4KLArsLYeSk3lHZT3Oe3mNFNHnhCC5NzDJlk3QcEA0 oP0KeXfKRY/BbROWKPneddrEju2YynWd3wFQjVFSWkJoON3YoJYApe+8qzszADHUcb3i 1/rbGsCzW5gnC2eQo3LA91LNldMuhLxf0syQMV9FMGQE0GNpHkUQOA1syHxEdvqhmmt/ wRTTL/b36eS+6GFtD0mTikdia8YW/VdAoGymfPspeeAX+BilvMPC2zIhX9zDYeXWljYE Q2wg== X-Forwarded-Encrypted: i=1; AJvYcCXDvlXNzjZ1inrUkLzJdr45wE/4cdKAB8HbnCsloxON/EOOwOWQPII49phJzWEF/smsx6vtkw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwDjNvPt/ReP+n7Fp2JmMgtsvr2VFMXYXHLD1qv9gAgchUtZYhm H5a9MTAZN7+wjfNmwl6+WliIFxmFWLemD0ZGj2ikhH7QHr2YdoCD7m9ePu7amvccE5ga+ZFt0Uj j3brQB2Zp1aAzvxBc1NxqrBK1MWWBzC5eW8U= X-Gm-Gg: ASbGnctWVuFVrz5S8jZ3+VfEd4y2cex9CLa6Ds5tipQH5ngZVwHcezATBkPN1Io1ULr uvzAmeBV4Zt3Ql/qlXLKkyyhWO29UCPPh7DOH/K7BUimQK9SLmmORKz8mbcXRiTfb3H0lT+U1rw == X-Google-Smtp-Source: AGHT+IFX8NojEKzHeqqII3oYvNb301HsfxwliXZ2RPODgXEQWdwkbkd5ZPRKytqci9INijb5fYa7O6OctQ5HflmB/rA= X-Received: by 2002:a05:6402:40c1:b0:5dc:d913:f89e with SMTP id 4fb4d7f45d1cf-5deade0b204mr195077a12.22.1739298349337; Tue, 11 Feb 2025 10:25:49 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Tue, 11 Feb 2025 10:25:48 -0800 From: Stefan Kangas In-Reply-To: <871pw4uzmo.fsf@metalevel.at> References: <83r1qy2m0d.fsf@gnu.org> <87v9ga6pwj.fsf@metalevel.at> <83mu1m2fhb.fsf@gnu.org> <83lfh62dr5.fsf@gnu.org> <871pw4uzmo.fsf@metalevel.at> MIME-Version: 1.0 Date: Tue, 11 Feb 2025 10:25:48 -0800 X-Gm-Features: AWEUYZkOxAk1usdRp1TTIOLNbuDuT2Wjhs5EtQrN4tnuDshOodsFB-9FV2scqu0 Message-ID: Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Markus Triska writes: > Stefan Kangas writes: > >> No further comments within 4 years. >> >> I'm therefore closing this bug report. > > I understand that you, as maintainers, close an existing report if you > do not consider at an issue. However, if there is any need to reconfirm > an existing issue every 4 years, then please consider this reply as such > reconfirmation. There is generally no reason to reconfirm issues every 4 years, no. I closed it because of this quote from Eli: > The conclusion is as before: an integer value of the 'line-height' > property cannot make the line's height on display smaller than the > default height. The previous discussion suggested that this is not a bug, but is working as expected. Since there had been no followups to that direct quote, I assumed that this settled the matter. If you still believe there's a bug here, could you please reply to the points made by Eli in his last reply on 2020-09-19 with a rationale? Thanks in advance. From unknown Mon Aug 18 17:53:57 2025 X-Loop: help-debbugs@gnu.org Subject: bug#43506: 26.1; line-height sometimes has no effect on the line height Resent-From: Markus Triska Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Feb 2025 19:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43506 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug To: Stefan Kangas Cc: 43506@debbugs.gnu.org, Eli Zaretskii Received: via spool by 43506-submit@debbugs.gnu.org id=B43506.173930377211714 (code B ref 43506); Tue, 11 Feb 2025 19:57:01 +0000 Received: (at 43506) by debbugs.gnu.org; 11 Feb 2025 19:56:12 +0000 Received: from localhost ([127.0.0.1]:58875 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1thwMe-00032s-5L for submit@debbugs.gnu.org; Tue, 11 Feb 2025 14:56:12 -0500 Received: from [78.47.144.35] (port=59200 helo=metalevel.at) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1thwMZ-00032d-Iz for 43506@debbugs.gnu.org; Tue, 11 Feb 2025 14:56:10 -0500 Received: by metalevel.at (Postfix, from userid 1000) id 46CC79C792; Tue, 11 Feb 2025 20:56:06 +0100 (CET) From: Markus Triska References: <83r1qy2m0d.fsf@gnu.org> <87v9ga6pwj.fsf@metalevel.at> <83mu1m2fhb.fsf@gnu.org> <83lfh62dr5.fsf@gnu.org> <871pw4uzmo.fsf@metalevel.at> Date: Tue, 11 Feb 2025 20:56:06 +0100 In-Reply-To: (Stefan Kangas's message of "Tue, 11 Feb 2025 10:25:48 -0800") Message-ID: <877c5wxnl5.fsf@metalevel.at> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Stefan Kangas writes: > The previous discussion suggested that this is not a bug, but is working > as expected. Since there had been no followups to that direct quote, I > assumed that this settled the matter. Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. [78.47.144.35 listed in bl.score.senderscore.com] 0.0 RCVD_IN_VALIDITY_SAFE_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. [78.47.144.35 listed in sa-trusted.bondedsender.org] 0.0 SPF_NONE SPF: sender does not publish an SPF Record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Stefan Kangas writes: > The previous discussion suggested that this is not a bug, but is working > as expected. Since there had been no followups to that direct quote, I > assumed that this settled the matter. Yes thank you, that is a completely understandable reason to close this: The behaviour I describe here is intended. Thank you and all the best, Markus