Re: [BUG] org-agenda-later sometimes creates a void display [9.7.11 (release_9.7.11 @ /usr/local/share/emacs/31.0.50/lisp/org/)]

[Michael Heerdegen <michael_heerdegen@web.de>]

Ihor Radchenko <yantar92@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.