Make a PostEvents container class for packaging several postevents

Make a PostEvents container class for packaging several postevents

Previously it was not possible to assign multiple postevents to a
single variable or pass them as the result of an event function.  This
patch wraps multiple events in such situations inside of a PostEvents
post-event and unwraps them when used again in the parser.

Defuse some open parens starting lines in strings in define-music-types.scm

Those confuse Emacs' heuristics and make it harder to edit subsequent
Scheme.

[lemzwerg, 2013-03-16 19:19:57]

LGTM.  The combination `\' `\n' `\(' is probably worth a comment in the
contributors' manual.

[dak, 2013-03-16 20:51:05]

On 2013/03/16 19:19:57, lemzwerg wrote:
> LGTM.  The combination `\' `\n' `\(' is probably worth a comment in the
> contributors' manual.

If \( was defined, things would be so much easier: one would just put \( in the
first column. \ <newline> \n( is the best I could manage.  Or reformat in order
to get the ( away from the starts of line.

Total nuisance.

[janek, 2013-03-17 16:37:19]

LGTM

[dak, 2013-03-23 20:36:32]

Rebasing too complex for pushing without additional testing.

[Ian Hulin (gmail), 2013-03-24 13:16:20]

On 2013/03/16 20:51:05, dak wrote:
> On 2013/03/16 19:19:57, lemzwerg wrote:
> > LGTM.  The combination `\' `\n' `\(' is probably worth a comment in the
> > contributors' manual.
> 
> If \( was defined, things would be so much easier: one would just put \( in
the
> first column. \ <newline> \n( is the best I could manage.  Or reformat in
order
> to get the ( away from the starts of line.
> 
> Total nuisance.

LGTM apart from a nitpick with the actual doc-string in define-music-types.scm. 
You probably got distracted by all the formatting stuff.

[Ian Hulin (gmail), 2013-03-24 13:20:15]

LGTM bar a nit-pick with the doc-string in define-music-types.scm. Sorry for the
previous message without the draft comment attached.
Cheers, Ian

https://codereview.appspot.com/7742044/diff/5001/scm/define-music-types.scm
File scm/define-music-types.scm (right):

https://codereview.appspot.com/7742044/diff/5001/scm/define-music-types.scm#n...
scm/define-music-types.scm:77: \n(no direction specified), and where @code{y} is
an articulation\
"\n(no direction specified or @code{-}), and when @code{y} is an articulation\"

[dak, 2013-03-24 13:36:42]

https://codereview.appspot.com/7742044/diff/5001/scm/define-music-types.scm
File scm/define-music-types.scm (right):

https://codereview.appspot.com/7742044/diff/5001/scm/define-music-types.scm#n...
scm/define-music-types.scm:77: \n(no direction specified), and where @code{y} is
an articulation\
On 2013/03/24 13:20:15, Ian Hulin (gmail) wrote:
> "\n(no direction specified or @code{-}), and when @code{y} is an
articulation\"

I did not actually change this documentation string, only formatted it
differently to stop it from throwing the whole Emacs indentation/highlighting
engine off.  And @code{-} _does_ not specify a direction but merely is a
syntactic marker not actually related to ArticulationEvent itself.

The whole documentation string is only so-so accurate (for example, one _can't_
have x = ^ and y "such as" -.) and the proposed change is more or less from
inaccurate to inaccurate without a real incremental improvement.

Now this patch has already been committed and this change is a separate commit
"Defuse some open parens starting lines...".  I don't consider it worth
reverting (and getting back the Emacs-confusing strings), but it would certainly
warrant a more accurate rewrite.  The proposed change in wording is not really
an improvement, however.

[Ian Hulin (gmail), 2013-03-25 11:52:13]

On 2013/03/24 13:36:42, dak wrote:
> https://codereview.appspot.com/7742044/diff/5001/scm/define-music-types.scm
> File scm/define-music-types.scm (right):
> 
>
https://codereview.appspot.com/7742044/diff/5001/scm/define-music-types.scm#n...
> scm/define-music-types.scm:77: \n(no direction specified), and where @code{y}
is
> an articulation\
> On 2013/03/24 13:20:15, Ian Hulin (gmail) wrote:
> > "\n(no direction specified or @code{-}), and when @code{y} is an
> articulation\"
> 
> I did not actually change this documentation string, only formatted it
> differently to stop it from throwing the whole Emacs indentation/highlighting
> engine off.  And @code{-} _does_ not specify a direction but merely is a
> syntactic marker not actually related to ArticulationEvent itself.
> 
> The whole documentation string is only so-so accurate (for example, one
_can't_
> have x = ^ and y "such as" -.) and the proposed change is more or less from
> inaccurate to inaccurate without a real incremental improvement.
> 
> Now this patch has already been committed and this change is a separate commit
> "Defuse some open parens starting lines...".  I don't consider it worth
> reverting (and getting back the Emacs-confusing strings), but it would
certainly
> warrant a more accurate rewrite.  The proposed change in wording is not really
> an improvement, however.

Agreed.  In that case LGTM.
Cheers,
Ian