Re: Parital scrolling of image

[storm@cua.dk (Kim F. Storm)]

David Kastrup <dak@gnu.org> writes:

>>> 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.

Does this still happen with my latest fixes?


>
> 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.

I think I have fixed this.  Please test.

> 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.

I put this on the FOR-RELEASE list.

I also fixed it so that when you move backwards into an image,
emacs now shows that bottom part of the image, rather than the
top part (which triggers the crash in sit-for).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk