Thank you for the reply. Ah, sorry I forgot to remove the parens to include
the `pop-to-buffer` within the defun.

About the 'restoring mechanism'; the global hook seems not to restore the
window selected before running the hook.

So here are the two separated test cases (they both use the 'pop-up'
function)

(defun pop-up ()
  (pop-to-buffer "pop-up"))

(defun test ()
  (interactive)
  (with-current-buffer (get-buffer-create "test")
    (add-hook 'window-configuration-change-hook #'pop-up)
    (pop-to-buffer "test")))

;; evaluate code to remove the (global) hook
(remove-hook 'window-configuration-change-hook #'pop-up)

(defun test ()
  (interactive)
  (with-current-buffer (get-buffer-create "test")
    (add-hook 'window-configuration-change-hook #'pop-up nil t)
    (pop-to-buffer "test")))


So the 'restoring mechanism' works like you explained for the local hook
but not for the global hook
(where after calling 'test', the pop-up buffer will be selected).

Also, I would expect that a hook just calls the hook function, and it would
not 'restore the window
 selected before the hook'. I would say the restoring is undesired behavior.



On Fri, 18 Mar 2022 at 09:37, martin rudalics <rudalics@gmx.at> wrote:

>  > I think it's a bad idea to do something that changes the window
>  > configuration in `window-configuration-change-hook'.  It's not
>  > unexpected to get an infinite recursion or any other unpredictable
>  > behavior.
>
> People should avoid it in packages because they could easily step on
> each other's toes.  Written carefully, it could be useful in private
> code.
>
> martin
>