emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Continuous image scrolling


From: Eli Zaretskii
Subject: Re: Continuous image scrolling
Date: Wed, 04 Apr 2018 09:27:53 +0300

> From: Clément Pit-Claudel <address@hidden>
> Date: Tue, 3 Apr 2018 17:57:35 -0400
> 
> AFAIU, one thing that is not too easy to implement today in ELisp is 
> continuous ("smooth") scrolling over multiple images, as shown in e.g. 
> evince: if I drag the scroll bars or press the up and down keys, the current 
> page and the following one move up and down by a bit.

It could/should be easy to implement in Lisp because the current
behavior is implemented in Lisp.  At least, I won't believe assertions
such as the above until Someone™ digs into the code in
line-move-visual and its subroutines, where the current behavior is
implemented, and presents clear evidence that some code or feature
coded in C gets in the way.

> The main issue, IIUC, is that images occupy one (tall) line, and Emacs tries 
> to always keep the line containing the point in full view, which means that 
> set-window-vscroll does not always work if the point is on a line containing 
> an image.

Yes, but most, if not all, of the logic supporting this is in
simple.el.

> But now put the point on the picture's line, and try the same experiment; 
> notice how the picture doesn't move, because we try to keep the line in full 
> view. (if the image is larger than the window, it does work, and that's how 
> docview scrolls single pages. I don't know if there's a way to get that 
> behavior when the image fits in the window).  That behavior becomes an issue 
> when you have sequences of images, because you can't leave the point on the 
> line of the first image, but moving the point to the line of the second image 
> scrolls it entirely into view.
> 
> The two techniques to work around this that I'm aware of are (1) cutting the 
> images into thin horizontal strips (and showing one strip per line), and (2) 
> inserting a thin text line between each image on which to place the point 
> while scrolling.  I don't know if either of these would work for pdftools.  
> Hopefully there's a third, simpler technique to achieve this?

It makes little sense to me to work around the behavior we ourselves
implemented.  Instead, I invite volunteers to take a good look at the
code and try changing it to lift the limitations that currently get in
the way.

The current code behaves like it does because it was _programmed_ to
behave that way.  It explicitly uses window-vscroll only when the
current line cannot be fully shown in the window for some reason.  But
if you look at the relevant code, you will see that this condition is
programmed there, and is specifically tested to determine when to use
window-vscroll and when to scroll to the next/previous screen line.
So by changing that logic, perhaps controlled by some defcustom, it
should be possible to get what DocView and PDF-tools want to
accomplish.

Let me remind you that similar misconceptions were around regarding
pixel-level scrolling of text, until Tak came up with his package that
did just that, entirely in Lisp.

I hope someone will step forward and do the necessary research of what
is needed, because my gut feeling is that the features sought out here
are within our reach.  (I can help with advice, because I'm
responsible for at least some of the code in that area.)

Any volunteers?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]