From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Continuous image scrolling Date: Wed, 04 Apr 2018 09:27:53 +0300 Message-ID: <83lge34hau.fsf@gnu.org> References: <87inaiss6l.fsf@web.de> <6FCF6ACA-4F29-4B6B-BE9D-D7130C6E9495@gnu.org> <87fu5moe4c.fsf@web.de> <877eqyocro.fsf@web.de> <83zi3uz4nb.fsf@gnu.org> <0b1dd3fa-e0b0-ed20-a256-dd92d1c1826f@dancol.org> <8bc3c4c7-dfc7-987a-95e7-bd309e2326c6@cs.ucla.edu> <03118DC0-39DA-4AB5-980E-A33809B9A5EE@raeburn.org> <86578165-1b41-e75c-7180-84d8edefc44b@grinta.net> <87d10i9qbx.fsf@mail.linkov.net> <87tvtucch8.fsf@telefonica.net> <87efjxibor.fsf_-_@mail.linkov.net> <87muyl59tw.fsf@telefonica.net> <87370c83io.fsf@mail.linkov.net> <3d9009a5-865c-98bd-b444-c24275291e65@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1522823181 9139 195.159.176.226 (4 Apr 2018 06:26:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 4 Apr 2018 06:26:21 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 04 08:26:16 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f3bs8-0002HJ-M6 for ged-emacs-devel@m.gmane.org; Wed, 04 Apr 2018 08:26:16 +0200 Original-Received: from localhost ([::1]:37143 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f3buE-0000yf-7G for ged-emacs-devel@m.gmane.org; Wed, 04 Apr 2018 02:28:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52447) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f3btb-0000yH-GQ for emacs-devel@gnu.org; Wed, 04 Apr 2018 02:27:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f3btY-0003Cf-6m for emacs-devel@gnu.org; Wed, 04 Apr 2018 02:27:47 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33395) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f3btY-0003CZ-3U; Wed, 04 Apr 2018 02:27:44 -0400 Original-Received: from [176.228.60.248] (port=3592 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1f3btX-0006L3-H1; Wed, 04 Apr 2018 02:27:43 -0400 In-reply-to: <3d9009a5-865c-98bd-b444-c24275291e65@gmail.com> (message from =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel on Tue, 3 Apr 2018 17:57:35 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:224302 Archived-At: > From: Clément Pit-Claudel > 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?