Michael Heerdegen writes: > Ihor Radchenko writes: > >> + (unless (< (point) wstart) ; do no scroll past the point >> + (set-window-start nil wstart)))) > > Thanks. > > Hmmm - don't we have the same problem when (point) > (window-end)? And > this case is nastier, since exact window-end calculation needs a > redisplay. We might introduce a flicker when trying to fix it. Right. What about the attached patch? > Since line lengths differ, we are currently setting window-start to a > random line, to some degree. (And I think window-start should better be > set to the beginning of line). I believe that Emacs redisplay should take care about this automatically. > One step back: What problem does this hack solve? Org already remembers > the unit number of the time period point is in, and restores that: with > point in a Wednesday, the new view will have point set to the beginning > of the next Wednesday. The display engine ensures that point is > made visible. https://orgmode.org/list/87lfh2hk4k.fsf@gmail.com/ > How about something like this? > > - If point is at bob, we ensure that point is restored at bob - and > likewise for eob. > > - When bob was visible in the prior view, we use window-start = 1 > for the new view, too > > - But when bob was not visible in the last view, we try to restore the > visible line number containing the window point, so that hitting f > will show the cursor at the same vertical position as in the last > view. Or maybe better: restore the vertical position of the > beginning of the weekday point was in. I hope that my idea in the patch is good enough and that we do not need to go into redisplay complications.