bug#35860: Delayed window positioning after buffer display

[martin rudalics]

> +(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