RE: [External] : display-buffer-alist actions

[Drew Adams]

> > My complaint is that we don't also provide some
> > simple to use constructs for simple use cases.
> >
> > But I do appreciate that it's still supported.
> > I hope it will continue to be so.  And I still
> > have hopes that the deprecation will be lifted
> > from it someday.  Users are in general unaware
> > of it now (it was removed from the manual etc.),
> > even though it's very good for the simple use
> > cases it handles.
> 
> I don't think keeping those vars around is the
> right solution (because those special-display*
> vars make the overall system more complex).
>
> Better would be to provide new ways to do the
> same, which are just as easy&simple but which
> rely on `display-buffer-alist`.

Apparently it's not "easy&simple" to provide new
ways to do the same, using `display-buffer-alist'.

That's the problem.  (Addition of such replacement,
just-as-easy&simple ways welcome...)

`display-buffer-alist' is indeed super-complex,
and it does let you configure many buffer-display
possibilities - even arcane ones.  But apparently
not these simple possibilities.

While waiting for the New, Miraculous, Easy&Simple
ways to get such easy&simple behavior, how about
we UN-deprecate this important feature that Just
Works, and put it back in the manual?
___

Zoom meetings provide lots of flexibility over
getting together physically, but who would think
the _addition_ of Zoom would be a good reason to
deprecate physical get-togethers?
___

 special-display-buffer-names
 special-display-frame-alist
 special-display-function
 special-display-regexps

Every one of those now has a big sign out front:

  "use `display-buffer-alist' instead"

And yet that's apparently not possible or
straightforward.  Or if it really _is_, then
please use `display-buffer-alist' to implement
easy&simple ways to get equivalent behavior.

Hasn't been done so far.  Yet we tell users to do it.