my attempt was

(add-to-list
     'display-buffer-alist
     '("\\*cider-log\\*" (display-buffer-reuse-window display-buffer-same-window)))

I did try setting switch-to-buffer-obey-display-actions but that did not seem to help.

If I redefine cider-log--switch-to-buffer with my own variant, where switch-to-buffer-other-window is replaced with display-buffer then it works as I expected. But on the other hand I know almost nothing about elisp so maybe I'm just doing something wrong.

I have

(add-to-list 'special-display-buffer-names '("*cider-log*" vemv.completions/split-window-vertically-small))

> If I redefine cider-log--switch-to-buffer with my own variant, where switch-to-buffer-other-window is replaced with display-buffer then it works as I expected. Yeah maybe my setup works because it does something different. It would seem plausible that display-buffer is more flexible than switch-to-buffer-other-window , so we'd be open to a PR in that direction

mkay. Adding *cider-log* to special-display-buffer-names causes the buffer to open in separate frame entirely

It depends, the function can do literally anything for you

In my example, vemv.completions/split-window-vertically-small is a defun that receives a buffer - one can do whatever with it

I have no idea about what's the preferred way to do stuff in emacs, but https://www.masteringemacs.org/article/demystifying-emacs-window-manager is quite adamant that libraries shouldn't use switch-to-buffer and I guess that might apply to switch-to-buffer-other-window. > I find that some packages and functions disregard all rhyme and reason and use switch-to-buffer instead of display-buffer when they want to show a buffer to the user. > This is wrong. And the net result is that your display rules won’t apply if this variable is not set to t.

It's confirmed then :) PR welcome

haha, I can barely manage writing my emacs config, it'll be a while before I'm brave enought to even dare thinking about opening a elisp PR 🙂

no issue, I'll give it a go soon then

great, thanks. but no hurry, I'm sure there's more important stuff than this to work on

In any case, the new logging functionality seems to work quite nicely, at least once I learn how to use logview better

I've enjoyed it across a couple commercial projects by now, total game changer. I use timbre/with-context+ a lot now, those contexts end up accessible in the Inspector which one can easily pop up by hitting RET on a log entry

yeah, logging context stuff can be quite nice when debugging

does the cider+logview support filtering by context btw? Like if some log item has {:user 123 ...} can I then somehow apply a filter to show only those lines?

Logjam (the JVM lib underpinning this stuff) says:

* `exceptions`
* `level`
* `pattern`
* `start-time`
* `end-time`
* `threads`
* `loggers-allowlist`
* `loggers-blocklist