bug#35860: Delayed window positioning after buffer display

[martin rudalics]

> BTW, there is a strange comment before the first line:
>
>      ;; Don't try this with NOFORCE non-nil!
>      (set-window-start window (point-min) t)
>
> but its NOFORCE is non-nil here.  Is this a FIXME-like reminder?

Rather a FIXME-like remainder.  I probably did try to fix something
here but don't recall any more if the comment applied to the version
before that fix or should apply to the present version (in which case
it is obviously wrong).

> In my previous patch there is no need to check for the buffer,
> because a new general variable is declared as buffer-local.

But the BUFFER argument of 'window--display-buffer' is not necessarily
the current buffer.  Or do I miss something?

>> What happens with these markers when 'display-buffer-no-window' gets
>> called?  Or some user provided routine provokes an unhandled error?
>> You don't even check the marker buffer of these variables so some old,
>> completely unrelated marker could get reused here.
>
> There is no global effect because this feature is localized
> to a single buffer by its buffer-local scope.

We would always have to assure that the marker's buffer and the
current buffer are the same.  And we would have to make sure the
marker gets reset when an unhandled error occurs.

> We could support an action alist too in addition to buffer-local variables,
> but we should leave an ability to set buffer-local variables, because
> neither view-lossage nor vc-git-print-log (two primary cases to test
> this feature) have no access to the 'action' arg of display-buffer.

Maybe we could provide a new macro which encapsulates the use of these
variables in a more disciplied fashion (providing the necessary action
arguments for `display-buffer').

martin