bug#18923: Alternative scrolling model

[Eli Zaretskii <eliz@gnu.org>]

> From: E Sabof <esabof@gmail.com>
> Cc: 18923@debbugs.gnu.org
> Date: Sun, 02 Nov 2014 19:09:20 +0000
> 
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> > > Imagine there is a buffer with **AN IMAGE** which occupies 30% of the window (ex. a diagram in an org-mode buffer). It's positioned at (window-start). I (scroll-up 1). I'd end up scrolling a lot more than the usual (= (default-line-height) 20) pixels, which is what I mean by "jump".
> 
> > If the problem is only with scrolling by single lines (or small
> > number of lines), then a very similar problem is already solved in
> > line-move-partial.  Try C-n in the same situation, and see if that's
> > what you want.  We could then use the same technique.
> 
> I'm not sure that we are talking about the same scenario. I didn't encounter any relevant behavior while using C-n/C-p, when a large image was displayed on the first line (with my default settings or Emacs -Q, both on the latest stable release).

Tell me how to reproduce the exact problem you are talking about, and
I will see if I understood the situation correctly.

> > I meant call window-body-height with PIXELWISE non-nil.  Then the
> > return value doesn't depend on what is displayed, it just gives you
> > the height of the text area in pixels.  Subtracting from that the
> > pixel coordinates of point returned by pos-visible-in-window-p or
> > posn-at-point will give you how many pixels are there to the top and
> > bottom of the window.  This should eliminate the need to count pixels
> > by moving one screen line at a time via vertical-motion, which is less
> > efficient, I think.
> 
> I'm not sure how knowing the distance of a point to the bottom of the window would benefit me, but indeed I could bulk-measure several lines in some cases.

IMO the most important case is when you need to scroll almost the full
window, in which case the pixel size of the window is the main piece
of information.