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

[martin rudalics]

> I haven't tried your new patch yet

... don't ...

> but I found pop-to-buffer-same-window
> + switch-to-buffer-obey-display-actions

... these are two different pairs of shoes:
'switch-to-buffer-obey-display-actions' is meant for customizing the
behavior of 'switch-to-buffer' - 'pop-to-buffer-same-window' should not
be affected by it ...

> 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

... IIUC this is more or less what I suggested just that I left
'reusable-frames' alone ...

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

Do you mean that we cannot separate the graphic and non-graphic cases
via 'display-buffer-alist'?  Too bad.

One problem is that 'display-buffer-pop-up-frame' has to get through as
'display-buffer-fallback-action' when everything else failed before -
even on a TTY.  So a new action alist entry like 'inhibit-pop-up-frame'
is needed - if t never pop up a new frame and if 'graphic-only pop up a
new frame on a graphic terminal only.  And ignore this entry in the
fallback case.  WDYT?

martin