Re: Doc: Reorganize music functions material. (issue970044)

[Carl . D . Sorensen]

I like the new suggestions.  Just a couple of comments.


http://codereview.appspot.com/970044/diff/1/2
File Documentation/extending/programming-interface.itely (left):

http://codereview.appspot.com/970044/diff/1/2#oldcode38
Documentation/extending/programming-interface.itely:38: * Music function
syntax::
On 2010/04/29 07:13:18, Mark Polesky wrote:
> Okay.  That makes me want to put "Simple substitution
> functions" back, but if I do that, is it better to copy the
> analagous node verbatim from the NR or to have the whole
> node be a stub linking to the NR?

I think a stub linking to the NR is correct.  Something like

Simple substitution functions are music functions whose output music
expression is written in LilyPond format and contains function arguments
in the output expression.  They are described in @ruser{Simple
substitution functions}.

http://codereview.appspot.com/970044/diff/1/3
File Documentation/notation/changing-defaults.itely (right):

http://codereview.appspot.com/970044/diff/1/3#newcode3641
Documentation/notation/changing-defaults.itely:3641: @ref{Music function
type predicates}.
On 2010/04/29 07:13:18, Mark Polesky wrote:
> On 2010/04/28 21:42:05, Neil Puttock wrote:
> > There's a danger here that users might think these are
> > the only type predicates allowed.
> >
> > The list's only complete in so far as type-p-name-alist
> > documents predicates used internally for music functions
> > and properties.

> There aren't that many other predicates out there (see

http://lists.gnu.org/archive/html/lilypond-devel/2009-08/msg00713.html).
> And I'm happy to add the remaining ones to the alist if
> that will justify using the word "complete".  (:

> You also proposed a clever way to prevent labeling failed
> type checks as "unknown" in the error message, which I'll
> definitely add to the next patch set

(http://lists.gnu.org/archive/html/lilypond-devel/2009-08/msg00725.html).

> I'd like to do both.

Users can also write their own type predicates if they want to.  So
perhaps we should mention "predefined type predicates"

http://codereview.appspot.com/970044/show