Re: Documenting buffer display

[martin rudalics]

> I disagree. If the behavior is documented in the command's doc
> string, as it should be, then the user is aware of it. Using a given
> command is a user choice. There is no reason to put on the hair
> shirt of not binding a user option in a user command, as long as
> the behavior is documented and the command ends always by
> restoring the user's preferred value for the option.

A user option has to be respected.  If the designer of a command sees
no other way to have a command do what it is supposed to do than by
overriding a user option we have a severe design problem.

'display-buffer' has no design problem because programmers can always
ask it to do what they want by specifying the ACTION argument
appropriately.  Telling programmers to bind a user option instead is
an invitation to bad design.

> Secondly, users themselves define commands, and the ability
> to bind such a variable - whether it is an option or not, is very
> useful for users.

And when such users become programmers we get our problems through the
backdoor, compare the recent "open bookmark in other frame" thread.

martin