On Thu, Jun 17, 2010 at 5:59 AM, Lennart Borgman wrote: > On Thu, Jun 17, 2010 at 5:10 AM, Lennart Borgman > wrote: >> On Thu, Jun 17, 2010 at 5:05 AM, Eli Zaretskii wrote: >>>> From: Stefan Monnier >>>> Cc: Lennart Borgman ,  storm@cua.dk,  emacs-devel@gnu.org,  david@harpegolden.net >>>> Date: Wed, 16 Jun 2010 20:54:52 -0400 >>>> >>>> Indeed what he suggests is probably impossible.  But the end result he's >>>> after is definitely possible: move the window-start as little as possible >>>> (tho still, line by line) to keep point displayed. >>> >>> xdisp.c already tries to do that, we just need to find out why it >>> fails in this particular case. >> >> After trying to restore the clip_changed value when save-restriction, >> widen etc unnecessarily changed I suddenly wonder why they changed it. >> Is not this something that only redisplay should handle? redisplay_can >> easily save the clipping when it sets clip_changed to 0 and compare >> with that when it enters redisplay_window and set clip_changed to 1 if >> the saved clipping does not match. >> >> Does that sound reasonable? (I do not know if I am missing something.) > > At least it works. I just tested. First time I am using Emacs without > "jumping scrolling"! :-) > > If you think this is the right way to fix it I will send patches later > when I cleaned up a bit. > > There is one more similar problem which I do not know how to handle, > in fileio.c. In the function Finsert_file_contents clip_changed is set > to 1. I am not quite sure of the impact of this but it looks wrong to > me to do this. I think the display engine should be told, but it must > decide what to do with redisplay, not fileio. Here is the patch (without the fileio.c part which I leave until I got some comments).