Implementation note: each invocation of accepting-values will probably need to maintain
a table that maps from a query identifier to the output record for the field that used the query
identifier, and the output record for each field in the dialog will probably need a mapping back
to the query identifier. A mediating object (a "query object") is also useful, for instance, as a
place to store the "changed-p" flag.

When own-window is non-nil, the dialog will appear in its own "popped-up" window. In this
case the initial value of stream is a window with which the dialog is associated. (This is similar
to the associated-window argument to menu-choose.) Within the body, the value of stream will
be the "popped-up" window. own-window is either t or a list of alternating keyword options
and values. The accepted options are :right-margin and :bottom-margin; their values control
the amount of extra space to the right of and below the dialog (useful if the user's responses
to the dialog take up more space than the initially displayed defaults). The allowed values for
:right-margin are the same as for the :x-spacing option to formatting-table; the allowed
values for :bottom-margin are the same as for the :y-spacing option.

Minor issue: When the programmer supplies :right-margin or :bottom-margin options
in the own-window argument, how is he supposed to determine what's needed? How about
providing an option to permit the window to resize itself dynamically? There really needs to be
a hook into note-space-requirements-changed or something. | barmar, SWM

exit-boxes specifies what the exit boxes should look like. The default behavior is though the
following were supplied:

 '((:exit " uses these values")
   (:abort " aborts"))

Minor issue: We need to describe the interpretation of the exit-boxes argument. Are other
keywords beside :exit and :abort permitted, such as :help? It's pretty common for a dialog
to have multiple ways to exit; perhaps accepting-values should return a second value that
indicates which exit box was selected. This alist looks sort of like a menu item list; perhaps the
full generality should be permitted (so that the style of the exit box messages can be specified).
The text strings that are shown in the default value look more like documentation than button
labels; I think both are necessary, and the programmer must be able to find out what the default
labels are so that he can include them in the documentation (rather than hard-coding ""
and ""). | barmar