Re: master 18b680cfd1: Fix bug#52467 by adding a new custom variable 'display-comint-buffer-action'

[Madhu]

* martin rudalics <8dfc6f22-d331-e7c1-b536-2d374197528f@gmx.at> :
Wrote on Fri, 31 Dec 2021 19:41:09 +0100:

>> Well, perhaps "unpredictable" is the wrong word.  But if we want to make
>> these commands behave the same (and I think we do), then some of them
>> have to change, and the change committed seems like the most consistent
>> and useful one.
>
> 'pop-to-buffer-same-window' was conceived as a stand-in for
> 'switch-to-buffer' so that people could customize it via
> 'display-buffer-alist'.  Using it as stand-in for 'pop-to-buffer' is
> tantamount to using 'switch-to-buffer' as stand-in for 'pop-to-buffer'.

I haven't tried your new patch yet but I found pop-to-buffer-same-window
+ switch-to-buffer-obey-display-actions inadequate for the sort of
behaviour required here, I had something like this (with the variable
set to t)

(defadvice pop-to-buffer-same-window
    (around reuse-existing-frame-advise
            (buffer-or-name &optional norecord) activate)
  (if current-prefix-arg
      ad-do-it
  (pop-to-buffer buffer-or-name
                 '((display-buffer-reuse-window
                    display-buffer-same-window)
                   . ((reusable-frames . 0)
                      (inhibit-same-window . nil)))
                 norecord)))

This would *for the most part* obey the customizations via pop-up-frames
and pop-up-windows or via display-buffer-alist (as the manual now
suggests. the latter is not easy to customize 'graphic-only, and fails
in many ways with packages like consult and transient)


> I'm not sure whether we should want to "make these commands behave the
> same".  But if we do, we have to provide some _simple_ knob to let users
> get the old behavior without having to think about how to match names of
> buffers they possibly never cared about with the help of a regular
> expression.