Ihor Radchenko <yanta...@posteo.net> writes: > That's what I tried myself. > I do not see any problem. > Please, do try to follow > https://orgmode.org/manual/Feedback.html#Feedback and provide detailed > steps showing how to reproduce the problem you are seeing without your > personal config.
This will be a lot of work. I really hope we can avoid it. > > I have a guess what the problem is. ... > > First, we need to establish whether the problem is with Org mode > itself or it is a combination of your config and Org mode. > > For now, I simply do not know what is that problem you are > experiencing. Because I cannot see it locally on my side. What I am seeing is what one sees for any window showing a sufficiently large buffer after evaluating something like (setf (window-start) (+ 10 (point-max))) and I have clearly shown that exactly that is what the code potentially does. I really don't want to spend half an hour to create a recipe until you at least think about what I said. I'm a big fan of recipes, really, but in this case I would have to prepare a complete fake org file with dozens of fake entries corresponding to suitable finely composed dates ... this will take unnecessarily long, can't you please just think about what I said? Five minutes? Please. Does restoring the result of (window-start) from the old agenda view, as a plain number(!), always give good results in your case? What happens for you in the scenario I described, when (window-start) of the previous view is larger than (point-max) of the new view? Emacs can't do anything but to show nothing when the end of the buffer lies "before" window-start. No? Michael.
