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

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

[Ihor Radchenko]

Hi,

According to 41.11 Line Height section of Elisp manual,

       A newline can have a ‘line-height’ text or overlay property that
    controls the total height of the display line ending in that newline.
    The property value can be one of several forms:
    
    ‘t’
         If the property value is ‘t’, the newline character has no effect
         on the displayed height of the line—the visible contents alone
         determine the height.  The ‘line-spacing’ property, described
         below, is also ignored in this case.  This is useful for tiling
         small images (or image slices) without adding blank areas between
         the images.

AFAIU, it implies that buffer-local `line-spacing' value is also
ignored.

Consider the following minimal example:

1. emacs -Q
2. (setq-default line-spacing 0.15)
3. (with-silent-modifications (insert-sliced-image (create-image "/path/to/some/image") nil nil 10 nil))

Expected: the spliced image is displayed without gaps.
Observed: visible gaps between image rows

If I understand correctly, `insert-sliced-image' tries to avoid the gaps
by (insert (propertize "\n" 'line-height t)). But it does not seem to be
working.

Am I missing something?

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

-- 
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>

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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Date: Wed, 08 Mar 2023 12:18:59 +0000
> 
> According to 41.11 Line Height section of Elisp manual,
> 
>        A newline can have a ‘line-height’ text or overlay property that
>     controls the total height of the display line ending in that newline.
>     The property value can be one of several forms:
>     
>     ‘t’
>          If the property value is ‘t’, the newline character has no effect
>          on the displayed height of the line—the visible contents alone
>          determine the height.  The ‘line-spacing’ property, described
>          below, is also ignored in this case.  This is useful for tiling
>          small images (or image slices) without adding blank areas between
>          the images.
> 
> AFAIU, it implies that buffer-local `line-spacing' value is also
> ignored.
> 
> Consider the following minimal example:
> 
> 1. emacs -Q
> 2. (setq-default line-spacing 0.15)
> 3. (with-silent-modifications (insert-sliced-image (create-image "/path/to/some/image") nil nil 10 nil))
> 
> Expected: the spliced image is displayed without gaps.
> Observed: visible gaps between image rows
> 
> If I understand correctly, `insert-sliced-image' tries to avoid the gaps
> by (insert (propertize "\n" 'line-height t)). But it does not seem to be
> working.
> 
> Am I missing something?

The above text in the manual is misleading: only the line-spacing
property of the same newline is ignored in this case.  (It makes no
sense to ignore the buffer-local value of line-spacing due to a single
newline, because the buffer-local value of line-spacing affects all
the lines in the buffer, not just one line.)  IOW, the line-height
property of the newline overrides the 'line-spacing' property of the
same newline.

I've updated the manual to be more accurate about this.  But other
than that, this is not a bug in the code.

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:

> I've updated the manual to be more accurate about this.  But other
> than that, this is not a bug in the code.

Thanks!

I agree that the current newline 'line-height property behaviour makes sense.
However, I still see `insert-sliced-image' inserting image with gaps as
a bug. Would it be possible to change `insert-sliced-image' so that it
overrides buffer-local `line-spacing' and forces no gaps?

-- 
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>

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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: 62048@debbugs.gnu.org
> Date: Wed, 08 Mar 2023 18:26:21 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I've updated the manual to be more accurate about this.  But other
> > than that, this is not a bug in the code.
> 
> Thanks!
> 
> I agree that the current newline 'line-height property behaviour makes sense.
> However, I still see `insert-sliced-image' inserting image with gaps as
> a bug. Would it be possible to change `insert-sliced-image' so that it
> overrides buffer-local `line-spacing' and forces no gaps?

Not easily, because the fact that the line-spacing variable affects
_all_ lines is deeply entrenched in the implementation: it computes
the corresponding metrics once and never changes that through the
entire redisplay of the window.

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:

>> However, I still see `insert-sliced-image' inserting image with gaps as
>> a bug. Would it be possible to change `insert-sliced-image' so that it
>> overrides buffer-local `line-spacing' and forces no gaps?
>
> Not easily, because the fact that the line-spacing variable affects
> _all_ lines is deeply entrenched in the implementation: it computes
> the corresponding metrics once and never changes that through the
> entire redisplay of the window.

I see.

The real problem I am trying to solve is scrolling images with large
heights. C-n/C-p and default scrolling jumps over the whole images as
they appear on a single line. It is annoying, especially when the image
is taller than the window height.

I was hoping to use `insert-sliced-image', but this `line-spacing' issue
makes the idea unreliable.

-- 
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>

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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: 62048@debbugs.gnu.org
> Date: Wed, 08 Mar 2023 20:39:13 +0000
> 
> The real problem I am trying to solve is scrolling images with large
> heights. C-n/C-p and default scrolling jumps over the whole images as
> they appear on a single line. It is annoying, especially when the image
> is taller than the window height.

That shouldn't happen: if an image is taller than the window, then
C-n/C-p use window-vscroll to scroll the image only partially, at
least as long as line-move-visual is non-nil (which it is by default).

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

[Ihor Radchenko]

[-- Attachment #1: Type: text/plain, Size: 2143 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> The real problem I am trying to solve is scrolling images with large
>> heights. C-n/C-p and default scrolling jumps over the whole images as
>> they appear on a single line. It is annoying, especially when the image
>> is taller than the window height.
>
> That shouldn't happen: if an image is taller than the window, then
> C-n/C-p use window-vscroll to scroll the image only partially, at
> least as long as line-move-visual is non-nil (which it is by default).

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.

I have experimented a bit using a very tall image and about a
screen-tall image from emacs -Q and recorded screencasts:

1. Scrolling a very tall image with C-n/C-p https://0x0.st/HibG.mkv
   - Emacs behaves nicely, except at the beginning/end of the image
   - At the beginning the image suddenly jumps half a screen
     May this behaviour be somehow customized?
   - At the end, the image disappears very quickly. Maybe something do
     to with end of buffer.

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?

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).

     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.

For future reference, I did the following in the screencasts:
1. Add several screens of newlines in *scratch* buffer
2. Insert one of the attached images in the middle of the buffer via
   (with-silent-modifications (insert-sliced-image (create-image "~/Downloads/drawing.svg")))
3. M-<
4. Scroll with mouse or with C-n/C-p


[-- Attachment #2: drawing.svg --]
[-- Type: image/svg\+xml, Size: 1548 bytes --]

[-- Attachment #3: wallpaper.png --]
[-- Type: image/png, Size: 37596 bytes --]

[-- Attachment #4: Type: text/plain, Size: 224 bytes --]


-- 
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>

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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: 62048@debbugs.gnu.org
> Date: Thu, 09 Mar 2023 09:13:13 +0000
> 
> > That shouldn't happen: if an image is taller than the window, then
> > C-n/C-p use window-vscroll to scroll the image only partially, at
> > least as long as line-move-visual is non-nil (which it is by default).
> 
> 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.

> 1. Scrolling a very tall image with C-n/C-p https://0x0.st/HibG.mkv
>    - Emacs behaves nicely, except at the beginning/end of the image
>    - At the beginning the image suddenly jumps half a screen
>      May this behaviour be somehow customized?
>    - At the end, the image disappears very quickly. Maybe something do
>      to with end of buffer.

No, it happens once the last part is seen in its entirety; see above
regarding the goal.

> 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.

> 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.

>      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.

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.
  . 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.

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>

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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: 62048@debbugs.gnu.org
> Date: Thu, 09 Mar 2023 10:55:09 +0000
> 
> 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.

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.

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:

>> 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?

> 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?
By providing a custom setting that will determine the threshold for
partial scroll: `line-move-height-threshold'. The default value will be
'window making lines taller than window height to trigger partial
scroll. Alternative values could be a subset of pixel specs, like (NUM)
or (X . UNIT).

Also, on the initial report. Is it possible to increase default
buffer-wise line-spacing via text property? (AFAIU, decreasing is
impossible).

-- 
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>

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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: 62048@debbugs.gnu.org
> Date: Sat, 11 Mar 2023 11:10:10 +0000
> 
> Eli Zaretskii <eliz@gnu.org> 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::.)