bug#19571: 25.0.50; `display-buffer-alist': ALIST is completely undefined

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 11 Jan 2015 21:14:47 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 19571@debbugs.gnu.org
> 
> > > ALIST is mentioned only here:
> > >
> > >  ACTION is a cons cell (FUNCTION . ALIST), where FUNCTION is a
> > >   function or a list of functions.  Each such function should
> > >   accept two arguments: a buffer to display and an alist of the
> > >   same form as ALIST.  See `display-buffer' for details.
> > >
> > > "of the same form as ALIST"?  Really?  What form is that?  Where is
> > > *anything* said about the form of ALIST?
> > 
> > It's an alist.  And you are referred to the documentation of
> > 'display-buffer' for details.  I see nothing wrong with that.
> 
> No, you are referred to `display-buffer' for ACTION - for info about
> everything in the ACTION paragraph.

Since (see above) "ACTION is a cons cell (FUNCTION . ALIST)",
describing ACTION also describes ALIST, which is part of ACTION.  IOW,
"everything in the ACTION paragraph" includes ALIST.

> Nothing says that the ALIST here is related to the ALIST mentioned
> for `display-buffer', at all.  Or if it is related somehow, nothing
> says how it is related.

The documentation of 'display-buffer' describes ACTION, and as part of
that describes ALIST.  See below.

> The ALIST mentioned for `display-buffer' is described in its doc
> string only as "an arbitrary association list (alist)."  Arbitrary.

That's not all 'display-buffer's doc has to say about ALIST.  It also
says:

  The `display-buffer' function builds a function list and an alist
  by combining the functions and alists specified in
  `display-buffer-overriding-action', `display-buffer-alist', the
  ACTION argument, `display-buffer-base-action', and
  `display-buffer-fallback-action' (in order).  Then it calls each
  function in the combined function list in turn, passing the
  buffer as the first argument and the combined alist as the second
  argument, until one of the functions returns non-nil.

This explicitly tells that ALIST is passed as argument to each
function in the list, and should be interpreted and handled by these
functions.  And now it should be clear why ALIST is arbitrary: its
form and semantics are entirely up to the author of the called
functions.

> In that case, we are left wondering, not about some predefined but
> unspecified form that ALIST must have, but rather what could possibly
> even be meant by the "form" that it takes concretely.  IOW, we wonder
> what kind of form conformance is required for the alist arg that
> FUNCTION must accept - in what way must it agree with the "form" of
> ALIST?

I don't understand the cause of your confusion about the form.  The
form of an alist is well known (and the doc string of 'display-buffer'
even spells out its full name -- "association list" -- to make it even
more clear.  What else should or could be said about the _form_ of an
alist whose components are up to the person or program that creates
that alist??

> But do with the doc string what you like.  If you find it perfectly
> clear, more power to you.  I'm just reporting that I find it
> confusing and not so helpful.  HTH.

I'm sorry, but I don't see how your report could be used to improve
the docs.  You claim that information is missing which is actually
there, and I pointed it out above.  You didn't identify any confusing
parts in the docs, nor suggested improvements to the existing text.
Would you please re-read the doc strings with the above in mind, and
point out what's confusing and/or suggest how to improve the existing
documentation?