Parital scrolling of image

Parital scrolling of image

[Kim F. Storm]

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 still need to look at wide images.

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

Re: Parital scrolling of image

[David Kastrup]

storm@cua.dk (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 still need to look at wide images.

Don't C-x < and C-x > provide all one needs for wide images?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Parital scrolling of image

[Richard Stallman]

    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.

Thanks very much for working on this.

Re: Parital scrolling of image

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> storm@cua.dk (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 still need to look at wide images.
>
> Don't C-x < and C-x > provide all one needs for wide images?

You are right that the functionality is there, so it is not
_necessary_ to do anything.

However these commands do "window-size scroll" rather than "column scroll".

With my patch C-n and C-p scrolls an image one line at a time, so I
think C-f and C-b should scroll one column for consistency...

But I guess this enhancement can wait until after the release
(it is pretty complex to achieve as it must not interfere with
the normal forward-char and backward-char functions.)

So for the moment I'll concentrate on scrolling tall images.

Re: Parital scrolling of image

[Kim F. Storm]

storm@cua.dk (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.


>
> I still need to look at wide images.

As I said in my response to David, I'll let this issue rest
until after the release.


I need to update docs and news, but it's getting late...

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

Re: Parital scrolling of image

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> storm@cua.dk (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), but instead the window will get vscrolled a
line.  This process repeats a few time: just vscrolling happens, but
point does not change the buffer position.  At some point of time
which does not appear overly related to how much of the image has
already scrolled off-screen, the image jumps back fully into sight,
and at the same time point moves one line down, finally.  If you keep
using C-n, again the very same image will vscroll off the screen for
several keypresses (while point does not change), then jump back to
fully visible at which time point finally moves one line down.

This isn't it yet.  As long as point can move down a line without
causing scrolling, it should do so.  Only when scrolling would occur
on movement should vscrolling be considered as an alternative to
actually moving point.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Parital scrolling of image

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

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

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

Re: Parital scrolling of image

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

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

Re: Parital scrolling of image

[David Kastrup]

[-- Attachment #1: Type: text/plain, Size: 1516 bytes --]

storm@cua.dk (Kim F. Storm) writes:

> David Kastrup <dak@gnu.org> writes:
>
>> 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.

Another note: when I execute scroll-down at the following screen shot
(where point is just at the bottom) I get "beginning of buffer"
signalled as an error and nothing changes (I have made sure that this
behavior will also occur when pre-command-hook and post-command-hook
are not modified by preview-latex, so they are not at fault here). As
you can see from the scroll bar, this is patently absurd: there are at
least four more screens of material worth, and although there are
quite a few images in there, there are a lot of positions in between
where point could stop if needed.  This is the standard "circ.tex"
file as delivered with the preview-latex package.  I don't consider
including the screen shot a shootable offense, since it is just 12kB.

Probably the pixel-based movement routines should more or less
calculate a maximum they should not exceed in movement (overshooting
by more than a screen certainly is bad), as well as a minimum they
should at least progress, and if "sane" movement does not land within
that area, then vscroll gets adjusted instead.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

[-- Attachment #2: scroll.png --]
[-- Type: image/png, Size: 12207 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Parital scrolling of image

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> storm@cua.dk (Kim F. Storm) writes:
>
>> David Kastrup <dak@gnu.org> writes:
>>
>>> 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.
>
> Another note: when I execute scroll-down at the following screen shot
> (where point is just at the bottom) I get "beginning of buffer"
> signalled as an error and nothing changes  [...]

P.S.: it does not really matter where point is on that page.  The
cursor will not move regardless where I execute scroll-down in the
displayed page.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Parital scrolling of image

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

>> Another note: when I execute scroll-down at the following screen shot
>> (where point is just at the bottom) I get "beginning of buffer"
>> signalled as an error and nothing changes  [...]
>
> P.S.: it does not really matter where point is on that page.  The
> cursor will not move regardless where I execute scroll-down in the
> displayed page.

You are right.  I just installed a fix.
Pls. try again.


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

Re: Parital scrolling of image

[Kim F. Storm]

David Kastrup <dak@gnu.org> 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.  Please test again -- and if you can still
reproduce it, pls. tell me how (and what is unintuitive about the
results you see).

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

I have also fixed a redisplay loop where resizing the frame that
displays your circ.tex with graphics loops trying to make the cursor
line fully visible.

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

True.

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

Inside the image, previous-line does scroll backwards.

It is true that if you use previous-line to move into a tall image
you get to the first part of that image rather than the last part
as you would expect.   I will see what I can do about it.

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

I think so too.

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

Re: Parital scrolling of image

[Ralf Angeli]

* Kim F. Storm (2005-01-24) writes:

> 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.
>
> I tried various things with your circ.tex, but I cannot reproduce this
> with my latest fixes.  Please test again -- and if you can still
> reproduce it, pls. tell me how (and what is unintuitive about the
> results you see).

The problem still exists.  If you need a small testcase, you can have
a look at the bug report I sent to emacs-pretest-bug on Saturday,
January 22nd. (<URL:http://spam.gmane.org/gmane.emacs.pretest.bugs:5428>)

-- 
Ralf

Re: Parital scrolling of image

[David Kastrup]

[-- Attachment #1: Type: text/plain, Size: 2466 bytes --]

storm@cua.dk (Kim F. Storm) writes:

> David Kastrup <dak@gnu.org> 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

[-- Attachment #2: twobugs.png --]
[-- Type: image/png, Size: 16695 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Parital scrolling of image

[Ralf Angeli]

* Ralf Angeli (2005-01-24) writes:

> The problem still exists.  If you need a small testcase, you can have
> a look at the bug report I sent to emacs-pretest-bug on Saturday,
> January 22nd. (<URL:http://spam.gmane.org/gmane.emacs.pretest.bugs:5428>)

Oops, sorry, cut-and-paste mistake.  The URL actually is
<URL:http://article.gmane.org/gmane.emacs.pretest.bugs:5428>.  With
the URL in the quoted text you actually mark the message as spam which
I hope is not desirable. (c:

-- 
Ralf

Re: Parital scrolling of image

[Kim F. Storm]

Ralf Angeli <angeli@iwi.uni-sb.de> writes:

>> I tried various things with your circ.tex, but I cannot reproduce this
>> with my latest fixes.  Please test again -- and if you can still
>> reproduce it, pls. tell me how (and what is unintuitive about the
>> results you see).
>
> The problem still exists.  If you need a small testcase, you can have
> a look at the bug report I sent to emacs-pretest-bug on Saturday,
> January 22nd. (<URL:http://spam.gmane.org/gmane.emacs.pretest.bugs:5428>)
>

Thanks.  I just installed a fix.

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

Re: Parital scrolling of image

[Ralf Angeli]

* Kim F. Storm (2005-01-24) writes:

> Ralf Angeli <angeli@iwi.uni-sb.de> writes:
>
>> The problem still exists.  If you need a small testcase, you can have
>> a look at the bug report I sent to emacs-pretest-bug on Saturday,
>> January 22nd.

[<URL:http://article.gmane.org/gmane.emacs.pretest.bugs:5428>]

> Thanks.  I just installed a fix.

Thank you.  The testcase in the article referenced above works fine
now.  However, there is a special case in circ.tex where some unwanted
behavior occurs.  You can reproduce it like that: Generate previews
for the whole document by typing `C-c C-p C-d'.  Move point to the
start of line 78 (you should be on an image with an equation starting
with "e+f=...").  Type `C-f' (this should open the preview).  Type
`C-p' to move on line up.  Point will end up in the line starting with
"stellt dann...", that means the line starting with "y-Wert..." will
be skipped.

-- 
Ralf

Re: Parital scrolling of image

[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

Re: Parital scrolling of image

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

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

Oh, you fixed it pretty soon, and I just checked that the behavior is
still fixed.

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

I've not seen the effect right now.  One thing that is apparent when
playing with scroll-down and scroll-up is that scroll-down tends to
jump to the start of an overtall image in one go, whereas using
scroll-up will go through an image in nice chunks.  I have also had a
few intermittent cases where scroll-up signaled "End of buffer" when
the buffer was not yet at the end.  I have not seen any crashes in the
current version though, and I'd hate to sacrifice _that_.

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

Uh, yes?  Oh, I see: that is for previous-line.  Yup, works.  What I
just reported was for scroll-down in contrast.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum