storm@cua.dk (Kim F. Storm) writes: > David Kastrup 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