bug#32790: 27.0.50; point jumps unexpectedly after delete-window

[martin rudalics]

> Do you see a problem with this implementation?

If 'switch-to-buffer-pop-to' is non-nil, you nevertheless run the
'force-same-window' rigmarole although 'pop-to-buffer-same-window'
might want to select a completely different window.  Please explain
this discrepancy unless I'm missing something completely obvious.

+(defcustom switch-to-buffer-pop-to nil
+  "If non-nil, use `pop-to-buffer-same-window' in the selected window.

Something like

"If non-nil, have `switch-to-buffer' run `pop-to-buffer-same-window'."

seems better.  BTW, I'm already thinking of calling this option
'switch-to-buffer-pop' because '-to' somehow requires an object where
to pop to and I doubt that a user will supply one.  Unless we do want
to allow a window here.

+This allows custmization of conditional actions for `display-buffer'."
                 ^

This option's doc would need more text, maybe a small example.

+        (set-window-data-p t))

Here I would write

         (set-window-start-and-point (not switch-to-buffer-pop-to))

(recall also that we use a trailing -p only for functions).

-     ((eq buffer (window-buffer)))
+     ((and (eq buffer (window-buffer))
+           (not switch-to-buffer-pop-to)))

This would show the buffer twice even when it already appears in the
same window, right?  Are you sure that this is TRT?  Unconditionally?

+          (unless (eq (selected-window) selected-window)
+            (setq set-window-data-p nil))))

Here I would then write

          (when (eq (selected-window) selected-window)
            (setq set-window-start-and-point t))))

and here instead of

+      (when set-window-data-p

I would use

      (when set-window-start-and-point

BTW your patch does not apply here well due to some whitespace
mismatches.

Thanks, martin