From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko 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 10:55:09 +0000 Message-ID: <87o7p2chyq.fsf@localhost> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11648"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 62048@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Mar 09 11:54:24 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 1paDug-0002pe-4I for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 09 Mar 2023 11:54:22 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1paDuO-0002MX-Ad; Thu, 09 Mar 2023 05:54: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 1paDuM-0002M3-MM for bug-gnu-emacs@gnu.org; Thu, 09 Mar 2023 05:54: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 1paDuM-0003AT-CX for bug-gnu-emacs@gnu.org; Thu, 09 Mar 2023 05:54:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1paDuL-0000hl-W8 for bug-gnu-emacs@gnu.org; Thu, 09 Mar 2023 05:54:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Mar 2023 10:54: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.16783592332688 (code B ref 62048); Thu, 09 Mar 2023 10:54:01 +0000 Original-Received: (at 62048) by debbugs.gnu.org; 9 Mar 2023 10:53:53 +0000 Original-Received: from localhost ([127.0.0.1]:51048 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1paDuC-0000hH-Ih for submit@debbugs.gnu.org; Thu, 09 Mar 2023 05:53:53 -0500 Original-Received: from mout01.posteo.de ([185.67.36.65]:36879) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1paDu9-0000gz-Ji for 62048@debbugs.gnu.org; Thu, 09 Mar 2023 05:53:50 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 5E1CE240066 for <62048@debbugs.gnu.org>; Thu, 9 Mar 2023 11:53:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1678359223; bh=ZKTR9yOqcSV/TWdLA9nqSGRgVozIxRkVvXlANuaqXi0=; h=From:To:Cc:Subject:Date:From; b=IKmdaHhcsHSxzoWy1HVDq8HJbV0ylwfj/7RYJwr+WfCWCxEDsbaa71AH17ayucY1W FHQ8AOORgO0g9HuvuyPWeBiRlJSpSbmDl6lSbrZ3PngVPhvzl4X2YBucNEzg5GYX9L JOhNVCnHoKDGyb9c1itlCMkF1Vsj6T2xRr0jFFaiSHoRlkonGWEIqNVLDgqVBMK9QG idd1KJaGnzch13SZtV/iGr+96+ER48Xmu9ia7xMRlBv3COvLHhWh9vkH//mrrcjk42 jL6Rsrexvujv5y6KqZxb5ZnMX2kSSD8dAXQqTcNeTYn8hoM1LHrsGOoQ2xbEoGtcUy enTC/noNwiKIg== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4PXQyt4tPRz9rxD; Thu, 9 Mar 2023 11:53:41 +0100 (CET) In-Reply-To: <83edpy2r3x.fsf@gnu.org> 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:257604 Archived-At: 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. >> 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 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). In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, cairo version 1.17.6) of 2023-02-13 built on localhost Repository revision: df5c1c9370ca3c6a6e119278ef6bb1e3bca4d578 Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12101007 System Description: Gentoo Linux Configured using: 'configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --datarootdir=/usr/share --disable-silent-rules --docdir=/usr/share/doc/emacs-30.0.9999 --htmldir=/usr/share/doc/emacs-30.0.9999/html --libdir=/usr/lib64 --program-suffix=-emacs-30-vcs --includedir=/usr/include/emacs-30-vcs --infodir=/usr/share/info/emacs-30-vcs --localstatedir=/var --enable-locallisppath=/etc/emacs:/usr/share/emacs/site-lisp --without-compress-install --without-hesiod --without-pop --with-file-notification=inotify --with-pdumper --enable-acl --with-dbus --with-modules --without-gameuser --with-libgmp --without-gpm --with-native-compilation=aot --with-json --without-kerberos --without-kerberos5 --without-lcms2 --with-xml2 --without-mailutils --without-selinux --without-sqlite3 --with-gnutls --without-libsystemd --with-threads --without-tree-sitter --with-wide-int --with-sound=oss --with-zlib --with-x --without-pgtk --without-ns --without-gconf --without-gsettings --without-toolkit-scroll-bars --with-xpm --with-xft --with-cairo --with-harfbuzz --without-libotf --without-m17n-flt --with-x-toolkit=no --with-gif --with-jpeg --with-png --with-rsvg --with-tiff --without-webp --with-imagemagick --with-dumping=pdumper 'CFLAGS=-march=native -O3 -pipe' 'LDFLAGS=-Wl,-O1 -Wl,--as-needed'' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS HARFBUZZ IMAGEMAGICK JPEG JSON LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY OLDXMENU PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF X11 XDBE XIM XINPUT2 XPM ZLIB Important settings: value of $LANG: en_US.utf8 locale-coding-system: utf-8-unix >> 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? >> 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'? 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. > 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. > . 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))) This is only for moving up, and the threshold appears to be window height. Do I understand correctly? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at