v2 (Custom function choice). Fix multiple misspellings of the variable `erc-buffer-display'. Simplify defcustom type from cons to plain function. Convert `displayed' frames variant to function item. Add escape hatch for no-op when buffer matches `window-buffer'. "J.P." writes: > Actually, instead of a `display-buffer' action alone, I went for a cons > of a `display-buffer'-compatible function, like `pop-to-buffer', and an > action argument, together. > > [...] > > For this new variant I'm proposing, ERC calls the user's function with > the newly created buffer and a possibly augmented version of the action > that includes some well defined contextual clues in its alist. The > latter are enumerated in the doc strings of the various user options. I've simplified this further. Instead of a cons of a `display-buffer'- compatible function and action, I think it's simpler to expect a function that takes as arguments the new buffer and a "context alist" (that can double as an "action alist"). This way, the user's code can inspect the context, assemble the action parameter appropriately, and dispatch `display-buffer' or similar as needed. I've also added some ready-made function items, though possibly only as placeholders. >> Although, at that point, why not just do >> >> (display-buffer (let ((erc-join-buffer 'bury)) (erc-tls :server ...)) >> '(my-use-dedicated-frame (inhibit-same-window . t))) >> >> which has always been possible and is no more complicated? > > This would be preferable if we had more granular options that only > affected a single context, such as something exclusively for > non-interactive `erc-tls' invocations. I've described this briefly in the doc string for `erc-buffer-display'.