Ihor Radchenko <yanta...@posteo.net> 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. At the risk of annoying you even more (I'm really sorry about that) - are you open to a small redesign? 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). 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. So that window-start thing does something different. I guess that the purpose of this is to make the switch visually more appealing, so that the eye is presented a similar perspective. But then, shouldn't we at least use a line based approach? Then, what the code is currently agnostic to is point at being at eob. This always annoyed me. 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. If you are open to the approach I could give it a try. Thanks, Michael.
