bug#62048: 30.0.50; Non-nil `line-spacing' takes precendence over 'line-height t text property

[Ihor Radchenko]

Eli Zaretskii <eliz@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>