Re: Parital scrolling of image

[David Kastrup]

address@hidden (Kim F. Storm) writes:

> David Kastrup <address@hidden> writes:
>
>> This looks much better.  But here are some remarks:
>>
>> a) an "open preview" that starts on a line of its own in preview-latex
>> has an overlay starting at the beginning of the line.  This overlay
>> has a before-string consisting of an image (display-property on a
>> single x character IIRC) followed by \n (so that the image will appear
>> on a line of its own).  Note that the image as well as the \n are not
>> connected to a character in the buffer, but appear just as
>> before-string.  Nevertheless, previous-line in the first _real_ line
>> of the overlay will be sufficiently confused as to not move at all.
>> Never.  This effect is probably not related to the very latest
>> changes, though.  I just noticed it when playing with the new code.
>> It leads to pretty unintuitive results, though.
>
> I tried various things with your circ.tex, but I cannot reproduce this
> with my latest fixes.

I can.  Generate previews, then walk with cursor left-right into a
preview that starts in the first column
(\begin{equation}...\end{equation} is a good candidate).  Then walk a
few cursor positions to the right, then cursor up.  The cursor will
just stick.  See bottom half of included screen shot for a scenario.

Then there is another one: if you have a small window with a partial
graphic at the bottom, and you use scroll-down, then the partial
graphic gets moved down pretty much as expected, only to scroll up
back on-screen when the cursor blinks.  That is: in some instances the
scrolling decisions do not survive cursor blinking.

See top half of included screen shot for a scenario.

>> b) Making a window as small as possible (2 lines or so) means that
>> scroll-down and scroll-up, that are supposed to scroll by a "near full
>> screen", namely `next-screen-context-lines' less than a full screen,
>> scroll, if at all, in the opposite direction than expected.  In case
>> that the `next-screen-context-lines' less than a full screen delivers
>> a negative or zero value, 1 should rather be substituted.
>
> I fixed this for pixel-based scrolling.

Seems to work.  One thing that surprised me is that the scroll bars (I
have no-toolkit scrollbars) do not seem to fall into the pixel-based
scrolling category: only whole images get moved, no vscroll effects
noticeable.  This is particularly obvious when dragging.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum