Re: The unwarranted scrolling assumption

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden,  address@hidden
> Date: Fri, 18 Jun 2010 11:11:27 -0400
> 
> >  . When try_window, called by try_scrolling, fails to find a proper
> >    place for cursor, after scrolling the window.  This means that the
> >    computed amount of scroll was incorrect: it didn't bring point into
> >    the view.  Not sure when this could happen.
> 
> This case sounds like the culprit.

I don't think so; this is just a generic "fire escape".

I think the place to look is here:

          /* Compute the distance from the scroll margin to PT
             (including the height of the cursor line).  Moving the
             iterator unconditionally to PT can be slow if PT is far
             away, so stop 10 lines past the window bottom (is there a
             way to do the right thing quickly?).  */
          move_it_to (&it, PT, -1,
                      it.last_visible_y + 10 * FRAME_LINE_HEIGHT (f),
                      -1, MOVE_TO_POS | MOVE_TO_Y);
          dy = line_bottom_y (&it) - y0;

According to my reading, it stops the search for point if it is more
than 10 lines below (resp above) the scroll margin.  The reason is
speed, as the comment says.  Can we safely assume that whoever sets
scroll-conservatively to the maximum value gives up this speed
consideration?  Or maybe we should have another option to replace the
hard-coded value of 10?