Re: display-buffer-alist simplifications

["Stephen J. Turnbull" <stephen@xemacs.org>]

Stefan Monnier writes:

 > My suggestion is to not merge them, basically.

XEmacs specifiers do not have a mode locale.  This means that in order
to get mode-specific behavior, you must write mode hook functions that
set up the various parameters per-buffer as they enter the mode.
Guess what?

This sucks for the mode author and is buggy for the user.

I think it's one of the primary reasons only core developers ever
explicitly manipulate specifiers.[1]

Merging really is not that hard to understand, and it's the way people
thing about things.  It sounds simpler to avoid conflict between the
particular implementation of merging and various people's intuitions
and/or needs of special cases, but the alternative is playing whack-a-
mole with the same bug reappearing every time somebody tries to copy
the behavior from one context to another.

This is not a drop-dead you lose argument for merging, but the
conditions for behaviors being discussed do seem to nest frequently:
user preference > mode > mode special buffer > user override.  I think
merging is very natural in this context, and should be considered at
some level.  Without it, the feature will not be used as often as mode
authors and users would like to.

Internal representation is a separate issue.  You can, of course, have
a fine-grained internal representation and merge at declaration time,
or you can simply store the user specs and merge at use time.  These
have subtly different semantics for display, and rather different
semantics if users want to query the spec database for some reason.

Footnotes: 
[1]  The other one is the unfortunate and buggy separation between
"glyph" and "image" objects.  Hi, David!