RE: display-buffer-alist simplifications

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

> >>> I'm lost here.  Do you mean that users who prefer the old
> >>> `display-buffer' behavior get overridden by the 
> >>> application whenever it passes an argument but do get the
> >>> old behavior when the application does not pass an argument?
> >>
> >> Yes.
> > Ouch.
> 
> Bah! Please don't let this happen. Other than being
> inconsistent/confusing/crazy (I'm not quite sure what the 
> "old behavior" means here), wasn't the main point of the
> rewrite to give power to the user? IOW, users must _always_
> be able to override what the application specified.

+1, yes.

But also vice versa!  A user can choose to use a command or mode that overrides
that user's saved option setting. Simple cases are `set-variable',
`customize-set-variable', `customize-set-value', and making a temporary change
in the Customize UI.

Such a command is Lisp code (an "application"). That does not automatically make
it anti-user or user-bullying. This is as true of code written by the same user
and 3rd-party code as it is of predefined option-setting commands such as
`set-variable'.

It's not simply about user option vs application code.  It's about how the
changes are made: by user request (in one form or another) or by programmatic
fiat (i.e., more or less beyond user control). It's all about respecting the
user. A user can choose to run code, and that code, just like a user setting,
should be able to take precedence.

This is what we do generally in Emacs.  We have saved user settings and code can
override those settings. It is up to the particular code to respect a user's
wishes and put itself at the demand (invocation) of users - e.g. in the form of
a command, minor mode, etc. There is no way to determine a priori whether any
given code is respectful of users in this way.

Attempts to order such things strictly are misguided. Each day that goes by
seems to see this discussion reshuffling the proposed override order or adding
new "levels" to it. No such tower of levels will suffice if you try to rely on
it to enforce things strictly. You will simply confuse the hell out of users
(and maintainers!) and frustrate anyone who tries to do anything unforeseen wrt
your order.

Some default ordering is fine, but there should be no attempt to prevent code
from overriding user settings etc. What we do with `default-frame-alist', face
definitons, etc. is reasonable: users can define their default preferences, but
they can also (e.g. using that bogeyman `code'') change things on the fly.

In Emacs more than other places, users can write code themselves, including code
that dynamically changes their own saved settings. This is Emacs 101.

> users must _always_ be able to override what the application specified.

sm> Don't worry about that.  We were only talking about the case where the
sm> user does not use buffer-display-alist.

Even if a user does use that option (or any other), code should still be able to
override such settings. Don't think automatically "code versus user"; think also
"code invoked on demand by user". There is code and there is code. Not all code
that overrides a saved user setting is doing something the user does not want.