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.