RE: display-buffer-alist simplifications

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

> > There is code and there is code.  Not all code that overrides a 
> > saved user setting is doing something the user does not want.
> 
> Which then would be code that overrides the user's settings in
> order to do what the user wants, right?

Exactly.  What a user wants is not necessarily limited to the user's saved
settings.  Those are essentially user-specific _defaults_, nothing more.

Users can sometimes want to override their own saved settings.  Nothing new
here.  User saved settings should not automatically trump everything else, and
they are not sacrosanct.

What is important is giving the user the control.  That includes letting users
run code that dynamically changes their default, saved values.  It includes code
that lets them save any such changes for future use.  It includes code that
users can use to do these things interactively (commands), and it includes code
that they might want to invoke in batch.

Of course it is important to let users _know_ (doc) if some given code they
might think about invoking binds or sets one of their saved settings.  But if
that behavior is well documented and the user chooses to invoke the code, then
yes, such code should be able to unabashedly change saved user settings.

That includes binding or setting a user option.  It is misguided to try to make
it difficult or impossible for code to do that.  What is important is who
controls/invokes the code, not whether the code changes user-specified default
behavior.

Several times in this discussion people have suggested that binding
`pop-up-frames', for example, is a no-no.  It is not.  What is a no-no is
binding such an option in code that a user might invoke without telling the user
what will happen.