bug#9532: 24.0.50; `special-display-regexps' is no longer respected

["Drew Adams" <drew.adams@oracle.com>]

> > I think the problem here is that display-buffer--special 
> > should not just be in display-buffer-fallback-action but
> > should take precedence over the ACTION argument (it's
> > largely equivalent to display-buffer-alist).
> 
> The problem with this is that if the "special" buffer is already
> displayed in a window, that window is supposed to be used instead of
> popping up a special window (at least, according to old behavior).

Yes, of course.  And it's not just "old behavior".  It's (part of) the
definition of "special-display" buffer.

> We could accomodate this...
> Then another problem arises: all direct switch-to-buffer calls will
> trigger special display for special buffers, which is not consistent
> with old behavior.

Not sure I follow.  Why is that not consistent with past behavior?  Why would we
not always want special display for special-display buffers?

Can you give an example for Emacs 23 and explain how the behavior would be
different for Emacs 24?

> The key difference here is that in Emacs 23 the `info' command
> calls display-buffer (using same-window-regexps to force
> it into the same window),

force it or not, depending on the value of `same-window-regexps' ;-)

> whereas currently `info' uses switch-to-buffer
> (with the intention of transitioning away from same-window-*).

Emacs 24 needs to respect `same-window-*'.  It needs to be compatible with past
Emacs behavior.

> OTOH, I don't see an easy way to handle all the backward
> compatibility exceptions in this case.

FWIW, Martin's code worked fine in this regard.

And please do not call these "exceptions".  Backward compatibility is backward
compatibility.  The various use cases that Emacs has always supported are not
"exceptions".

What sounds like "exceptions", to me (but I'm not sure because I'm not clear
about what you mean), are proposed changes like not always having
special-display buffers be displayed as such (see above - your "not consistent
with old behavior").

The new code needs to DTRT, supporting the same use cases supported in the past.
In particular, it needs to support special-display in the same ways.

It is OK to change how that support is implemented.  It is not OK to remove that
support.

> One possibility is to change `info' etc. back to using
> same-window-regexps with display-buffer, which mostly kicks the
> can down the road to a later release.  Or maybe we should just require
> use of display-buffer-alist for this case.
> 
> Any thoughts?

Perhaps look to Martin's code for an answer?  Even if you decide not to do
everything the same way he did it, perhaps for things like this his code can
help guide you.  Dunno.