From: martin rudalics <rudalics@gmx.at>
To: Drew Adams <drew.adams@oracle.com>, emacs-devel <emacs-devel@gnu.org>
Subject: Re: Documenting buffer display
Date: Sun, 21 Oct 2018 10:22:14 +0200 [thread overview]
Message-ID: <5BCC3736.1010305@gmx.at> (raw)
In-Reply-To: <10ed3b66-ca9d-4431-8a56-0b1f10ebc799@default>
> 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
next prev parent reply other threads:[~2018-10-21 8:22 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-20 12:20 Documenting buffer display martin rudalics
2018-10-20 13:21 ` Eli Zaretskii
2018-10-20 18:02 ` martin rudalics
2018-10-21 12:56 ` Eli Zaretskii
2018-10-22 9:06 ` martin rudalics
2018-10-22 13:55 ` Eli Zaretskii
2018-10-22 19:14 ` martin rudalics
2018-10-22 19:27 ` Eli Zaretskii
2018-10-23 8:58 ` martin rudalics
2018-10-23 11:26 ` Pierre-Yves Luyten
2018-10-23 13:45 ` martin rudalics
2018-10-23 17:40 ` Stefan Monnier
2018-10-23 14:04 ` Drew Adams
2018-10-23 18:18 ` martin rudalics
2018-10-23 15:18 ` Eli Zaretskii
2018-10-23 18:23 ` martin rudalics
2018-10-23 19:07 ` Eli Zaretskii
2018-10-24 9:44 ` martin rudalics
2018-10-24 14:48 ` Eli Zaretskii
2018-10-24 17:40 ` martin rudalics
2018-10-24 18:25 ` Eli Zaretskii
2018-10-25 20:42 ` Juri Linkov
2018-10-23 15:52 ` Alan Mackenzie
2018-10-23 18:25 ` martin rudalics
2018-11-08 19:25 ` martin rudalics
2018-10-22 1:39 ` Michael Welsh Duggan
2018-10-22 5:54 ` Eli Zaretskii
2018-10-20 15:22 ` Drew Adams
2018-10-20 18:02 ` martin rudalics
2018-10-20 18:24 ` Drew Adams
2018-10-21 8:22 ` martin rudalics [this message]
2018-11-04 9:06 ` martin rudalics
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5BCC3736.1010305@gmx.at \
--to=rudalics@gmx.at \
--cc=drew.adams@oracle.com \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.