Re: Parital scrolling of image

[David Kastrup]

address@hidden (Kim F. Storm) writes:

> David Kastrup <address@hidden> writes:
>
>> address@hidden (Kim F. Storm) writes:
>>
>>> address@hidden (Kim F. Storm) writes:
>>>
>>>> A brief message to let you know that I've started to look into
>>>> the problem of scrolling through images that are higher/wider
>>>> than the current window.
>>>>
>>>> I've already have a working solution for tall images.
>>>
>>> I have installed my changes.  They modify line-move and
>>> scroll-up, scroll-down.
>>>
>>> If you have problems with this, set auto-window-vscroll to nil.
>>
>> Cough, cough.  If I have a window with the upper half taken up by an
>> image, and point is in some normal text below the image, then pressing
>> C-n will _not_ move to the next line (which is perfectly on screen and
>> quite far from the edge),
>
> I have checked in some patches to fix this.  Please try again.

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.

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.

This should be a general paradigm: all window-based movement/scrolling
commands should make _some_ progress, and in the _expected_ direction.

c) when pressing next-line, an image will get scrolled in smaller
chunks (by the way, maybe one should be able to configure the size of
those chunks).  That is nice.  previous-line shows no such behavior,
however: it scrolls an image with one big jump.  A bit of symmetry
here would probably be nice to have.

That being said, the behavior we now have for next-line is much much
better than what was available at any previous time.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum