From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#62048: 30.0.50; Non-nil `line-spacing' takes precendence over 'line-height t text property Date: Sat, 11 Mar 2023 14:28:51 +0200 Message-ID: <83pm9fwjy4.fsf@gnu.org> References: <87ilfbe8r0.fsf@localhost> <83a60n40an.fsf@gnu.org> <87y1o7cd6a.fsf@localhost> <834jqv3tv3.fsf@gnu.org> <87v8jbc70u.fsf@localhost> <83v8ja2z4d.fsf@gnu.org> <87sfeecmom.fsf@localhost> <83edpy2r3x.fsf@gnu.org> <87o7p2chyq.fsf@localhost> <83zg8m15n5.fsf@gnu.org> <87r0tvwnl9.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22370"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 62048@debbugs.gnu.org To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Mar 11 13:30:20 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1payMc-0005bR-GV for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 11 Mar 2023 13:30:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1payMP-00019Y-UN; Sat, 11 Mar 2023 07:30:05 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1payMO-00019K-0m for bug-gnu-emacs@gnu.org; Sat, 11 Mar 2023 07:30:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1payMM-0003U0-PV for bug-gnu-emacs@gnu.org; Sat, 11 Mar 2023 07:30:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1payMM-0006nL-Jn for bug-gnu-emacs@gnu.org; Sat, 11 Mar 2023 07:30:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 11 Mar 2023 12:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62048 X-GNU-PR-Package: emacs Original-Received: via spool by 62048-submit@debbugs.gnu.org id=B62048.167853775626030 (code B ref 62048); Sat, 11 Mar 2023 12:30:02 +0000 Original-Received: (at 62048) by debbugs.gnu.org; 11 Mar 2023 12:29:16 +0000 Original-Received: from localhost ([127.0.0.1]:56728 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1payLb-0006ll-Nb for submit@debbugs.gnu.org; Sat, 11 Mar 2023 07:29:16 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:57460) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1payLZ-0006lY-Dt for 62048@debbugs.gnu.org; Sat, 11 Mar 2023 07:29:14 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1payLT-0003Mb-Cs; Sat, 11 Mar 2023 07:29:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=VwCSZTkvQHQ1ArGXyMkP2Nk1ow7VujPopuhEwDTY8YE=; b=ZgLglGmltIxG9VeAlNJ+ pfvERgBc8WiclJTMM0W50sp2uBWEk9SYAhdORfuNA9sU6FzgdxdX6GoOHZMqMutwQUWHQsWINlGdE 2ApB0MXjnYXfFejy59PG97n6OYuH6/y4zuhmQ72hc/vjNpiinf+x4F5mbv2/V2nVz/dsHLo6Ivev7 GwO1ad5+tpOsIrpY5gjZy+QQuBD1zhfDSYM4ZgCyJ5EcfDfug8wCvBov+YEFhyD3fDf10Ig+r9bjm hDv+w9cK6r6nqOXoM85Kb9XAkA+wIvBEsWcTKS4t/4uFS+h7rREWxbuA30B4UbRTLyTM/pELABByQ rjmNv1pGCGCXEA==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1payLR-0006H0-3o; Sat, 11 Mar 2023 07:29:06 -0500 In-Reply-To: <87r0tvwnl9.fsf@localhost> (message from Ihor Radchenko on Sat, 11 Mar 2023 11:10:10 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:257786 Archived-At: > From: Ihor Radchenko > Cc: 62048@debbugs.gnu.org > Date: Sat, 11 Mar 2023 11:10:10 +0000 > > Eli Zaretskii writes: > > >> Observed: top of the image is displayed > >> Expected: bottom of the image is partially revealed > > > > I don't understand the expectation. Scrolling by vscroll only happens > > when before the scroll some part of the image is visible, which is not > > what happens here. > > > > If you want to change that, feel free to hack on the code in > > simple.el, but there was no intent to cover this particular use case, > > and the code is already quite complicated (to say the least). > > ... > > You should always keep in mind that Emacs has no idea about what's > > beyond the window, for display purposes. There's no way of saying > > whether a given 'display property whose value is an image spec will be > > taller than the window, except by actually displaying that image (or > > at least simulating the display internally). So you expect something > > that it is far from easy to do. > > > > Scrolling commands were never meant to allow smooth scrolling through > > tall screen lines. > > What if the code instead tries to vscroll standard line height first and > only then decide if we want to scroll further, displaying tall line? You mean, use vscroll even for lines whose height is the same as the default font? That'd be a waste, no? And how do you propose to "decide if we want to scroll further"? > > What do you want to customize, and in what terms? > > I was referring to > > >> (if (and (< arg 0) > >> (< (point) (window-start)) > >> (> lh winh)) > >> (set-window-vscroll > >> nil > >> (- lh dlh) t))) > > May we allow users to customize ~(> lh winh)~ condition? I don't mind, but make sure some other place in this set of twisty little passages don't assume we test against the window's height. > Also, on the initial report. Is it possible to increase default > buffer-wise line-spacing via text property? (AFAIU, decreasing is > impossible). The mechanism for overriding doesn't depend on the value, it depends on the hierarchy of settings, as the ELisp manual describes. When the manual says "However, no matter what you specify, the actual line height can never be less than the default", it means the default height described in the previous paragraph: The height of the line contents is the maximum height of any character or image on that display line, including the final newline if there is one. (A display line that is continued doesn’t include a final newline.) That is the default line height, if you do nothing to specify a greater height. (In the most common case, this equals the height of the corresponding frame’s default font, see *note Frame Font::.)