[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Continuous image scrolling
From: |
Clément Pit-Claudel |
Subject: |
Re: Continuous image scrolling |
Date: |
Tue, 3 Apr 2018 17:57:35 -0400 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 |
On 2018-04-03 15:59, Juri Linkov wrote:
>> i.e. it is not possible to finely scroll the sequence of images up and
>> down, you go one image at the time.
> It's because next-line goes to the next file in Dired by default,
> this is why I disabled this inconvenience in my ~/.emacs by using
> normal cursor motion keybindings:
Maybe I'm misunderstanding the original request, but if not then I don't think
this is the issue.
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.
We usually call this pixel-scroll in Emacs, and we have an implementation of it
based on set-window-vscroll in lisp/pixel-scroll.el. This is also what Docview
and PDFTools use to scroll images that don't fit in the selected window. But I
don't think that trick works for sequences of images, at least not straight out
of the box.
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.
You can see what I mean concretely with the following example. Open a new
buffer, and run (insert (propertize " " 'display '(image :type jpeg :file
"/path/to/some/large/picture.jpg" :scale 1))). Then insert 5 lines of "A".
Your buffer will look like this:
|----------------|
| Picture here |
| |
|----------------|
A
A
A
A
Put the point on the third A and run (set-window-vscroll (selected-window) 8
t); note how the images moves a bit up. That's the kind of scrolling we want,
which is encouraging :)
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?
Clément.
- Continuous image scrolling (was: What improvements would be truly useful?), Juri Linkov, 2018/04/02
- Re: Continuous image scrolling, Óscar Fuentes, 2018/04/02
- Re: Continuous image scrolling, Eli Zaretskii, 2018/04/03
- Re: Continuous image scrolling, Juri Linkov, 2018/04/03
- Re: Continuous image scrolling, Stefan Monnier, 2018/04/03
- Re: Continuous image scrolling,
Clément Pit-Claudel <=
- Re: Continuous image scrolling, Eli Zaretskii, 2018/04/04
- Re: Continuous image scrolling, Juri Linkov, 2018/04/04
- Re: Continuous image scrolling, Eli Zaretskii, 2018/04/05
- Re: Continuous image scrolling, Tak Kunihiro, 2018/04/04
- Re: Continuous image scrolling, Clément Pit-Claudel, 2018/04/04
- Re: Continuous image scrolling, Tak Kunihiro, 2018/04/04
- Re: Continuous image scrolling, Clément Pit-Claudel, 2018/04/05
- Re: Continuous image scrolling, Tak Kunihiro, 2018/04/05
- Re: Continuous image scrolling, Clément Pit-Claudel, 2018/04/06
- Re: Continuous image scrolling, Tak Kunihiro, 2018/04/06