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: Thu, 09 Mar 2023 14:16:46 +0200 Message-ID: <83zg8m15n5.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36550"; 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 Thu Mar 09 13:18:39 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 1paFEE-0009IT-3k for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 09 Mar 2023 13:18:38 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1paFDg-0001ku-9j; Thu, 09 Mar 2023 07:18:04 -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 1paFDe-0001aK-JO for bug-gnu-emacs@gnu.org; Thu, 09 Mar 2023 07:18:02 -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 1paFDe-0004iy-AG for bug-gnu-emacs@gnu.org; Thu, 09 Mar 2023 07:18:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1paFDd-0003Oe-OF for bug-gnu-emacs@gnu.org; Thu, 09 Mar 2023 07:18:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Mar 2023 12:18:01 +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.167836422912985 (code B ref 62048); Thu, 09 Mar 2023 12:18:01 +0000 Original-Received: (at 62048) by debbugs.gnu.org; 9 Mar 2023 12:17:09 +0000 Original-Received: from localhost ([127.0.0.1]:51087 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1paFCm-0003NM-LY for submit@debbugs.gnu.org; Thu, 09 Mar 2023 07:17:09 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:35028) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1paFCk-0003Ml-0X for 62048@debbugs.gnu.org; Thu, 09 Mar 2023 07:17:07 -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 1paFCe-0004Y7-6A; Thu, 09 Mar 2023 07:17:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=TH9OGq7xNehIzmznnQbHwAuJbUVNqgFVZUtnfMPCmWQ=; b=WsmPZyYiyT0T GSRvEEFzFvtE4KO4UktW+A+XufSuaPZ8IX0XQkWgN1tpvBZrQKWtcUDsF7LXLbnC6hDc05zWkpg9X 3vbc3fE2FFbEhLWNDWZHAA0HMaII5z1uVGHhwBaWKpZDXBRLaPNRZZYoydhUZw1P5vTZfQggPM1J5 ch3+B6u0mbT8JZiNPHNGss0gzhZ9vaT5Xa6caBriwkB0OJM1w++F6dFyTsnOa5OYB8SknhzQJ2pHE mZw5WgOEKf/+ciKvvLiP4X+oTvDdT31xjErxvwwqFG00VfshZcXKVEkFHT1N0TxNLXPBNm/tOBo6X Z2/D9Ykr8l6pUtQh9lQ4uQ==; 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 1paFCV-00030A-OZ; Thu, 09 Mar 2023 07:16:59 -0500 In-Reply-To: <87o7p2chyq.fsf@localhost> (message from Ihor Radchenko on Thu, 09 Mar 2023 10:55:09 +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:257607 Archived-At: > From: Ihor Radchenko > Cc: 62048@debbugs.gnu.org > Date: Thu, 09 Mar 2023 10:55:09 +0000 > > Eli Zaretskii writes: > > >> Interesting. I did not notice this because this feature only manifests > >> itself on really tall images. The images that are about screen height > >> still feel jumpy. > > > > AFAIU the code, this is intentional: the goal of using vscroll in > > C-n/C-p is to make sure the user can see all the parts of the tall > > image. Smooth scrolling is not the goal; if you want that, try > > pixel-scroll-precision-mode. > > I do use pixel-scroll-precision-mode myself. However, it only works with > a mouse - not the most common interaction model with Emacs. > > Further, the comment on top of `line-move' implies that it already > performs a mixed role. > > ;; This is like line-move-1 except that it also performs > ;; vertical scrolling of tall images if appropriate. > ;; That is not really a clean thing to do, since it mixes > ;; scrolling with cursor motion. But so far we don't have > ;; a cleaner solution to the problem of making C-n do something > ;; useful given a tall image. > > Documentation > Move forward ARG lines. > > If NOERROR, don't signal an error if we can't move ARG lines. > TO-END is unused. > TRY-VSCROLL controls whether to vscroll tall lines: if either > auto-window-vscroll or TRY-VSCROLL is nil, this function will > not vscroll. > > So, smooth scrolling is partially a goal, de facto. No, it isn't: the doc string never says anything about smooth scrolling (and if it did, that would be a lie). Also note the "if appropriate" part. > >> 2. Scrolling a very tall image with mouse https://0x0.st/Hibk.mkv > >> - Unexpectedly, most of the tall image is skipped upon mouse scroll. > >> Bug? > > > > I cannot reproduce this on my system, using drawing.svg you posted and > > another large image I have here. Mouse scrolls behave for me like > > C-n/C-p does. > > Exact steps: > 1. emacs -Q > 2. M-: (with-silent-modifications (insert-sliced-image (create-image "~/Downloads/drawing.svg"))) > 3. scroll up with mouse > 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). > I can sometimes observe similar issue when scrolling across an image in > other scenarios. I have a feeling that scrolling is always done properly > when the point is on image line right before mouse scrolling. When point > is on other lines, I sometimes see unexpected jumps of even a hang (C-g > works). 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. > >> 3. Scrolling a near-screen tall image with C-n/C-p https://0x0.st/Hibn.mkv > >> - Note how the image goes across the screen in just a few "jumps" > >> (C-n strokes). This is the commonly observed behaviour in the images > >> I often deal with. Probably something to do with what initial > >> half-screen jump in (1). > > > > If it jumps after all the portions of the image have been seen, and > > the last portion is completely visible, that's the intended behavior. > > Sure. Can it be made customizable? What do you want to customize, and in what terms? > >> I think that jumping half screen at the beginning/end of the image > >> is too drastic, especially for images near as tall as screen > >> height. It would help if this behaviour is fixed or made > >> customizable. > > > > That's because you expect something C-n/C-p weren't programmed to do, > > see above. If someone wants to work on making the scrolling more > > smooth, I won't object, but the current code doesn't try to provide > > smooth scrolling, only a chance to see the whole image part by part. > > Is all the relevant code in `line-move'? That in line-move-partial, AFAIR. > I had difficulties with debugging `line-move' because debugger > performs redisplay and I see image scrolled half-way even before > entering `line-move' in the debugger. Welcome to the club. printf (a.k.a. "message") debugging is your friend. > > Please don't forget: > > > > . The code in C-n/C-p that scrolls partially is not only for tall > > images, it is also for tall text (try using a very large font for > > some face or part of the buffer text). The relevant parts of > > Emacs treat tall screen lines the same no matter what caused the > > large height, whether an image or some tall text. > > Sure. But if we are talking about this much tall text, human eye will > treat it as an image anyway. I see no problem with preferring more > smooth scrolling here. We are mis-communicating: I actually meant the situation where the text is taller than the default, but not too tall. I also disagree with your assessment of what the human eye will do: I think that is only true if what you see in a single window-full is illegible (because the text is too tall or the window too small in height). In all other cases, the human eye has no problem reading the text if, for example, the window shows 3/4 of the text. Images are different in this respect. > > . The code in C-n/C-p needs to strike a fine balance between smooth > > scrolling and user expectation that text that is not too large be > > scrolled one line at a time, i.e. that you won't need several > > C-n/C-p key strokes to move the display by a single screen line. > > As image height goes smaller and smaller, at some point it is > > reasonable to expect that a single C-n/C-p will scroll across the > > entire line which contains the image, not just some part of that > > line. The question is where to draw the line (pun intended); the > > code has some heuristic regarding that. > > Are you referring to the follow excerpt from `line-move': > > ;; If we moved into a tall line, set vscroll to make > ;; scrolling through tall images more smooth. > (let ((lh (line-pixel-height)) > (edges (window-inside-pixel-edges)) > (dlh (default-line-height)) > winh) > (setq winh (- (nth 3 edges) (nth 1 edges) 1)) > (if (and (< arg 0) > (< (point) (window-start)) > (> lh winh)) > (set-window-vscroll > nil > (- lh dlh) t))) There's a similar code in line-move-partial as well.