Option to limit current-window-only to org-agenda and org-capture

[rtrppl]

In its current version current-window-only affects all calls to switch-to-buffer-other-window. A user, however, may want to limit the scope of current-window-only to, for example, org-agenda and org-capture. The following modification of the function current-window-only--switch-to-buffer-other-window would do just this:

(defvar current-window-only-buffers '("*Org Select*"
			" *Agenda Commands*")) ; Names of buffers to which current-window-only should be applied

(defun current-window-only--switch-to-buffer-other-window
    (buffer-or-name &optional norecord)
   (let ((buffer-name-str (if (bufferp buffer-or-name)
                             (buffer-name buffer-or-name)
                           (if (symbolp buffer-or-name)
                               (symbol-name buffer-or-name)
                             buffer-or-name))))
  (if (or (member buffer-or-name current-window-only-buffers)
	  (and (stringp buffer-name-str)
	       (string-match-p "CAPTURE" buffer-name-str)))
      (switch-to-buffer buffer-or-name norecord t)
(pop-to-buffer buffer-or-name t norecord))))

[FrostyX]

Thank you for the RFE @rtrppl,

Generally, my approach so far was "This is an opinionated package and it is all or nothing". But there have been requests to opt out for certain modes. For example Magit, which is now documented in the README - https://github.com/FrostyX/current-window-only?tab=readme-ov-file#tips-and-tricks

So it may be worth it to add some level of configuration.

The current-window-only-buffers is a good idea but I am thinking something even more general. Something like having a predicate function that would be used inside of

(defun current-window-only--switch-to-buffer-other-window
    (buffer-or-name &optional norecord)
  (switch-to-buffer buffer-or-name norecord t))

(defun current-window-only--delete-other-windows
    (&optional window interactive)
  (ignore window)
  (ignore interactive))

The predicate would be entirely user-defined. If it was evaluated to t, then current-window-only--switch-to-buffer-other-window and current-window-only--delete-other-windows would simply call the function they are overriding. If nil then they would do the actual code making the buffer display in the current window.

The question is, what arguments should it take, if any? And will it work for everybody who wants to opt-out in some circumstance?

[FrostyX]

Another approach that I've been thinking about was having a possibility to enable current-window-only-mode as a buffer-local minor mode. But I haven't implemented any buffer-local modes yet, so I don't know if this is even doable.

[rtrppl]

Both ideas sound reasonable. I also have no experience with buffer-local modes. As a user I just wanted more control over the scope of current-window-only - more specifically to limit it to org-capture and org-agenda. I don't have any other packages that misbehave in a similar way (in fact, I was told on Mastodon that Org 9.7 would "will respect display-buffer-alist", which would eliminate the need to micro-manage windows).