bug#35860: Delayed window positioning after buffer display

[martin rudalics <rudalics@gmx.at>]

 > +(defvar delayed-window-point nil

Name space conventions would recommend 'window-delayed-point'.

 > +  "Marker to override default `window-point' in all windows.

Why "marker" and why "all windows"?  As for the former, I think it
makes sense because then one can specify an insertion type as well.
But IIRC you earlier wanted to allow plain integers here too?

 > +`delayed-window-point' is a buffer-local marker you can move to a valid
 > +position of the buffer shown in the window in order to override the standard
 > +positioning mechanism (`point-min') chosen by window displaying functions.")

IIUC there is no such "mechanism" except for buffers just created.
And what about 'switch-to-buffer-preserve-window-point'?  "window ???
displaying functions" implicitly hints at the fact that the mechanism
works only when the buffer is shown by 'display-buffer'.  But are we
sure that this restriction always applies?

Otherwise the patch looks good.

 > Frankly speaking, macros like with-help-window, with-temp-buffer-window
 > are terribly ugly and look like a kludge.  For example, after applying
 > the following patch, all source files that use the changed macro,
 > need to be recompiled, so everyone will need to do bootstrap after
 > pushing it, and many other problems.

Until Lars comes up with a solution that detects any changed macros,
finds their users, and orderly recompiles the respective files.  But
I'm afraid he's turning back to his books for now.

 > I see no reason to use macros here.
 > We need to replace these macros with the elegant solution that we already
 > have of using action alists.

Macros are useful in as much as they allow to specify the evaluation
order of their arguments.  Action alists are dumb in this regard.

martin