[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Parital scrolling of image
From: |
David Kastrup |
Subject: |
Re: Parital scrolling of image |
Date: |
Mon, 24 Jan 2005 16:27:37 +0100 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux) |
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
- Re: Parital scrolling of image, (continued)
- Re: Parital scrolling of image, Richard Stallman, 2005/01/21
- Re: Parital scrolling of image, Kim F. Storm, 2005/01/21
- Re: Parital scrolling of image, David Kastrup, 2005/01/22
- Re: Parital scrolling of image, Kim F. Storm, 2005/01/22
- Re: Parital scrolling of image, David Kastrup, 2005/01/23
- Re: Parital scrolling of image, Kim F. Storm, 2005/01/24
- Re: Parital scrolling of image, Ralf Angeli, 2005/01/24
- Re: Parital scrolling of image, Ralf Angeli, 2005/01/24
- Re: Parital scrolling of image, Kim F. Storm, 2005/01/24
- Re: Parital scrolling of image, Ralf Angeli, 2005/01/24
- Re: Parital scrolling of image,
David Kastrup <=
- Re: Parital scrolling of image, David Kastrup, 2005/01/23
- Re: Parital scrolling of image, David Kastrup, 2005/01/23
- Re: Parital scrolling of image, Kim F. Storm, 2005/01/24