Re: Documenting buffer display

[martin rudalics <rudalics@gmx.at>]

 > 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