Package: emacs;
Reported by: Ihor Radchenko <yantar92 <at> posteo.net>
Date: Wed, 8 Mar 2023 12:18:01 UTC
Severity: normal
Found in version 30.0.50
View this message in rfc822 format
From: Ihor Radchenko <yantar92 <at> posteo.net> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 62048 <at> debbugs.gnu.org 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
Eli Zaretskii <eliz <at> gnu.org> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.