Re: Set-window-vscroll sometimes doesn't work

[Yuan Fu]

> 
>>> Once again: scroll-up/down normally scroll by whole window, or by its
>>> large fraction.  It is not a good idea to mix that with pixel-wise
>>> scrolling of images.
>> 
>> AFAICT mouse wheel scrolling uses scroll-up/down, so a smooth scrolling 
>> behavior for scroll-up/down is not unreasonable.
> 
> Mouse-wheel scrolling doesn't set window-start, it sets vscroll
> instead.  So you indeed can use that paradigm as well, as long as you
> make sure the argument to scroll-up/down is a small number.
> 
> But my point was that you shouldn't set window-start if you need to
> use a non-zero vscroll.

It does: mwheel-scroll calls scroll-down/up, which calls 
window_scroll_pixel_based, which sets w->start (and it sets vscroll for tall 
image).

> 
>>>> With my limited knowledge, setting window-start (aka scroll) and setting 
>>>> vscroll in the same time is the only way to to get what I want. But it is 
>>>> against the design of the display engine. Is there anyway out of this?
>>> 
>>> Not without rewriting significant parts of the display code.  Forcing
>>> window-start and setting vscroll conceptually contradict each other,
>>> so your interpretation of avoiding the contradiction by doing one and
>>> then the other is bound to cause problems in other use cases.
>> 
>> I’d love to know more about this part. For me, window-start and vscroll seem 
>> to be unrelated: changing vscroll doesn’t really affect window-start. 
>> Couldn’t the redisplay do something like “move window to start at 
>> window-start then scroll down vscroll pixels”?
> 
> The idea behind the current design is that if you set window-start,
> you want to see the stuff at that position in its entirety.  Having
> non-zero vscroll would prevent that, because some of the tall image is
> not visible.
> 
> It is, of course, possible to use some other concept, but the current
> concept is assumed in several places, and you will have to change them
> all.
> 

I see.

>>> That is why I suggest to stick to the code in simple.el as much as
>>> possible: it is well tested and works, AFAIU you need to change it
>>> very little to be able to scroll images that are smaller than the
>>> window height -- that test is in a small number of places and can be
>>> replaced by something else.
>>> 
>> 
>> next-line and friends only vscroll when scroll-conservatively=0 and ARG=1, 
>> which allows it to get away from the problem I face (set-window-start and 
>> set-window-vscroll in the same time). I either implements smooth scrolling 
>> to only work when ARG=1 or I need to set both value at the same time.
> 
> I don't understand why you say this.  First, C-n works on tall images
> with arguments greater than 1.  And second, I still don't understand
> why you need to set window-start, because vscroll should be enough for
> your needs, as far as I understand.

C-n doesn’t smooth scroll on tall images when ARG > 1: The code checks for ARG 
= 1, if not, it doesn’t do line-move-partial. I also tried C-2 C-n, no smooth 
scrolling.

I thought vscroll is a relative measure and is measured against window-start. 
And it kind of makes sense to set a window start as the basis and set vscroll 
based on that. So I kind of assumed that window-start is always at least 
partially visible and vscroll is always less than the height of the first line. 
Now, if I throw away window-start and scrolls entirely by vscroll, will there 
be any problems? Like, does anyone relies on window-start being visible? I felt 
like that’s what people uses to get the first line displayed in the window.

Yuan