Document <> and improve other simultanous music documentation.

Document <> and improve other simultanous music documentation.

This is a side issue of 2522: it improves the documentation dealing
with various ways of entering parallel music and gives the necessary
information to understand <> as a special case of chords.

[Ian Hulin (gmail), 2012-06-01 17:08:19]

Mostly LGTM.  Better idea than putting the stuff in a doc-string for a
\placeholder function people would hardly ever use.

If you really don't like the extra @cindex that's fine.

The other changes are just stylistic things so the English reads with a better
flow.

Cheers,

Ian

http://codereview.appspot.com/6248080/diff/6001/Documentation/notation/simult...
File Documentation/notation/simultaneous.itely (right):

http://codereview.appspot.com/6248080/diff/6001/Documentation/notation/simult...
Documentation/notation/simultaneous.itely:82: 
@cindex placeholder events

http://codereview.appspot.com/6248080/diff/6001/Documentation/notation/simult...
Documentation/notation/simultaneous.itely:83: A chord acts merely as container
for the notes inside and ornamentations
"A chord merely acts as a container for notes inside it and and allows
articulations or ornaments to be added consistently to all notes inside."

http://codereview.appspot.com/6248080/diff/6001/Documentation/notation/simult...
Documentation/notation/simultaneous.itely:84: added to it.  As one consequence,
a chord without notes inside does not
"As a consequence, a ..."

http://codereview.appspot.com/6248080/diff/6001/Documentation/notation/simult...
Documentation/notation/simultaneous.itely:86: articulations.  As another, there
is considerable leeway for arranging
"Furthermore, there is ..."

[dak, 2012-06-01 20:12:57]

http://codereview.appspot.com/6248080/diff/6001/Documentation/notation/simult...
File Documentation/notation/simultaneous.itely (right):

http://codereview.appspot.com/6248080/diff/6001/Documentation/notation/simult...
Documentation/notation/simultaneous.itely:82: 
On 2012/06/01 17:08:19, Ian Hulin (gmail) wrote:
> @cindex placeholder events

I have my doubts that people will think of that keyword, but I don't have a
better candidate.

http://codereview.appspot.com/6248080/diff/6001/Documentation/notation/simult...
Documentation/notation/simultaneous.itely:83: A chord acts merely as container
for the notes inside and ornamentations
On 2012/06/01 17:08:19, Ian Hulin (gmail) wrote:
> "A chord merely acts as a container for notes inside it and and allows
> articulations or ornaments to be added consistently to all notes inside."

No, that would be wrong.
<a-1 c-1 e-1> is different from <a c e>-1 and
<a\p c\p e\p> is different from <a c e>\p

http://codereview.appspot.com/6248080/diff/6001/Documentation/notation/simult...
Documentation/notation/simultaneous.itely:84: added to it.  As one consequence,
a chord without notes inside does not
On 2012/06/01 17:08:19, Ian Hulin (gmail) wrote:
> "As a consequence, a ..."
"As a consequence" ... "Furthermore" is not a pairing like "As one consequence"
... "As another".  In this case, I'd likely just write "Consequently," ...

[Trevor Daniels, 2012-06-01 21:40:17]

LGTM, apart from one nitpick

http://codereview.appspot.com/6248080/diff/11001/Documentation/notation/simul...
File Documentation/notation/simultaneous.itely (right):

http://codereview.appspot.com/6248080/diff/11001/Documentation/notation/simul...
Documentation/notation/simultaneous.itely:89: (for more possibilities,
@pxref{Simultaneous expressions}):
For consistency, please use @ref{} in the NR

[Keith, 2012-06-01 22:21:46]

The issue was that s1*0 can affect the default duration of the next note, while
<> does not, but the solution of <> was tempered by opinions that <> is cryptic.

s1*0 is rarely used.  The uses I find, in documentation and mutopiaproject, are
to attach a post-fix notation to an object where it is inconvenient or
impossible to postfix the notation.

This patch fails to explain how <> solves the difficulty for with people have
used s1*0.  Instead, it demonstrates the considerable leeway to transform clear
input to cryptic input, without changing the resulting output.

http://codereview.appspot.com/6248080/diff/11001/Documentation/notation/simul...
File Documentation/notation/simultaneous.itely (right):

http://codereview.appspot.com/6248080/diff/11001/Documentation/notation/simul...
Documentation/notation/simultaneous.itely:86: duration but can still be useful
for attaching articulations.
The text implies that <> is useful for placing articulations where there are no
notes, such as a delayed turn, 
  \relative c'' \new Staff {g2. <>\turn a4}
but <> is not useful here, since we need parallel spacer rests anyway,
  \relative c'' \new Staff<<{g2. a4} {s2 s2\turn}>>

[dak, 2012-06-02 06:26:57]

On 2012/06/01 22:21:46, Keith wrote:
> The issue was that s1*0 can affect the default duration of the next note,
while
> <> does not, but the solution of <> was tempered by opinions that <> is
cryptic.

This implies that this patch is trying to solve the issue.  It doesn't.  It
merely provides the information required to see what chords in general are and
how <> fits in, and to see what << >> in general is (and in particular what it
is not) and how chords fit in.  This information was conspiculously absent for
the most part.

This is groundwork.  It does not actually tackle issue 2522, merely makes it
easier to start.

> s1*0 is rarely used.  The uses I find, in documentation and mutopiaproject,
are
> to attach a post-fix notation to an object where it is inconvenient or
> impossible to postfix the notation.
> 
> This patch fails to explain how <> solves the difficulty for with people have
> used s1*0.  Instead, it demonstrates the considerable leeway to transform
clear
> input to cryptic input, without changing the resulting output.

I agree that the examples don't show a useful application: that would actually
already constitute part of issue 2522: not just telling how <> works, but how it
can be useful.

The intent of the examples is to show equivalences.  Of course, only one of the
equivalences is ever needed.  At this section of the manual, more
complex/abstract constructs that are _better_ solved using <> and/or parallel
music are not easy to come by without exceeding the complexity already
understood by the reader.

So I welcome any examples/passages which do the job better.  I agree with you
that the question "why?" is not answered.

[dak, 2012-06-02 06:44:30]

http://codereview.appspot.com/6248080/diff/11001/Documentation/notation/simul...
File Documentation/notation/simultaneous.itely (right):

http://codereview.appspot.com/6248080/diff/11001/Documentation/notation/simul...
Documentation/notation/simultaneous.itely:86: duration but can still be useful
for attaching articulations.
On 2012/06/01 22:21:47, Keith wrote:
> The text implies that <> is useful for placing articulations where there are
no
> notes, such as a delayed turn, 
>   \relative c'' \new Staff {g2. <>\turn a4}

I don't read that into the text.  How about
"useful in situations where articulations can't be attached to their target
because it is already embedded in a different music construct."

And something like
<>-\markup \italic marcato \repeat unfold 8 c'

as example?

[Keith, 2012-06-02 06:49:01]

On Fri, 01 Jun 2012 23:26:57 -0700, <dak@gnu.org> wrote:

> The intent of the examples is to show equivalences.  Of course, only one
> of the equivalences is ever needed.  At this section of the manual, more
> complex/abstract constructs that are _better_ solved using <> and/or
> parallel music are not easy to come by without exceeding the complexity
> already understood by the reader.

> So I welcome any examples/passages which do the job better.

  music = \relative c'' { e16 d c d }
  { f'4 <>\marcato \music r <>^"smorz." \mp \> \music <>\! }

[Keith, 2012-06-02 06:58:19]

On Fri, 01 Jun 2012 23:44:30 -0700, <dak@gnu.org> wrote:

>
>
http://codereview.appspot.com/6248080/diff/11001/Documentation/notation/simul...
> File Documentation/notation/simultaneous.itely (right):
>
>
http://codereview.appspot.com/6248080/diff/11001/Documentation/notation/simul...
> Documentation/notation/simultaneous.itely:86: duration but can still be
> useful for attaching articulations.
> On 2012/06/01 22:21:47, Keith wrote:
>> The text implies that <> is useful for placing articulations where
> there are no
>> notes, such as a delayed turn,
>>    \relative c'' \new Staff {g2. <>\turn a4}
>
> I don't read that into the text.  How about
> "useful in situations where articulations can't be attached to their
> target because it is already embedded in a different music construct."
>


That's better.
I'd say "... but can take articulations and notations,
which will be engraved as if they were attached to a note
starting at the musical moment of the empty chord."

[dak, 2012-06-02 07:28:37]

"Keith OHara" <k-ohara5a5a@oco.net> writes:

> On Fri, 01 Jun 2012 23:26:57 -0700, <dak@gnu.org> wrote:
>
>> The intent of the examples is to show equivalences.  Of course, only one
>> of the equivalences is ever needed.  At this section of the manual, more
>> complex/abstract constructs that are _better_ solved using <> and/or
>> parallel music are not easy to come by without exceeding the complexity
>> already understood by the reader.
>
>> So I welcome any examples/passages which do the job better.
>
>  music = \relative c'' { e16 d c d }
>  { f'4 <>\marcato \music r <>^"smorz." \mp \> \music <>\! }

Incidentally, something like
atLast =
#(define-music-function (parser location post music)
   (ly:event? ly:music?)
   (let ((final
	  (fold-some-music
	   (lambda (m) (or (music-is-of-type? m 'rhythmic-event)
			   (music-is-of-type? m 'event-chord)))
	   (lambda (m p) m)
	   #f
	   music)))
     (if final
	 (set! (ly:music-property final 'articulations)
	       (cons post (ly:music-property final 'articulations)))
	 (ly:music-warning music "No place for post-event"))
     music))

music = \relative c'' { e16 d c d }
{ f'4 <>\marcato \music r <>^"smorz." \mp \> \atLast \! \music }

looks nicer, but is not exactly manual material.

-- 
David Kastrup

[dak, 2012-06-02 08:09:36]

On 2012/06/02 07:28:37, dak wrote:

> >  music = \relative c'' { e16 d c d }
> >  { f'4 <>\marcato \music r <>^"smorz." \mp \> \music <>\! }
> 
> Incidentally, something like
> atLast =
> #(define-music-function (parser location post music)
>    (ly:event? ly:music?)
>    (let ((final
> 	  (fold-some-music
> 	   (lambda (m) (or (music-is-of-type? m 'rhythmic-event)
> 			   (music-is-of-type? m 'event-chord)))
> 	   (lambda (m p) m)
> 	   #f
> 	   music)))
>      (if final
> 	 (set! (ly:music-property final 'articulations)
> 	       (cons post (ly:music-property final 'articulations)))
> 	 (ly:music-warning music "No place for post-event"))
>      music))
> 
> music = \relative c'' { e16 d c d }
> { f'4 <>\marcato \music r <>^"smorz." \mp \> \atLast \! \music }
> 
> looks nicer, but is not exactly manual material.

In this case, compare what happens if you follow this up with
c\f c c c

The solution with <>\! will essentially get ignored, and the
descrescendo ends in forte.  The solution with \atLast will, in
contrast, end the descrescendo independently from \f and placed at a
different vertical position much better reflecting the musical
meaning.

It would seem that _trailing_ <> are not really something we should
lightly suggest since it is unknown what their articulations will
attach themselves to.

[dak, 2012-06-02 09:56:57]

http://codereview.appspot.com/6248080/diff/11001/Documentation/notation/simul...
File Documentation/notation/simultaneous.itely (right):

http://codereview.appspot.com/6248080/diff/11001/Documentation/notation/simul...
Documentation/notation/simultaneous.itely:89: (for more possibilities,
@pxref{Simultaneous expressions}):
On 2012/06/01 21:40:17, Trevor Daniels wrote:
> For consistency, please use @ref{} in the NR

What consistency?  Texinfo has a variety of reference commands that are
formatted differently according to the position in sentence.  Regarding @ref,
the documentation states:

  In general, it is best to use `@ref' only when you need some word
other than "see" to precede the reference.  When "see" (or "See") is
ok, `@xref' and `@pxref' are preferable.

Can you point to a coding standard or rationale for LilyPond regarding only
using @ref?

Is this related to translations?

[Trevor Daniels, 2012-06-02 12:18:26]

On 2012/06/02 09:56:57, dak wrote:

> What consistency? 

For consistency with the rest of the LilyPond documentation.

> Can you point to a coding standard or rationale for LilyPond
> regarding only using @ref?

Yes.  

CG 5.4.2: To create links, use @ref{} if the link is within the same manual.

And CG 5.3.6 Cross references, which gives a list of the commands to be used in
LilyPond documents.
 

Trevor

[dak, 2012-06-02 13:59:35]

tdanielsmusic@googlemail.com writes:

> On 2012/06/02 09:56:57, dak wrote:
>
>> What consistency?
>
> For consistency with the rest of the LilyPond documentation.
>
>> Can you point to a coding standard or rationale for LilyPond
>> regarding only using @ref?
>
> Yes.
>
> CG 5.4.2: To create links, use @ref{} if the link is within the same
> manual.
>
> And CG 5.3.6 Cross references, which gives a list of the commands to be
> used in LilyPond documents.

It does not say _not_ to use other constructs.  I'll have to see what
happens, anyway.

-- 
David Kastrup

[Graham Percival, 2012-06-02 14:23:12]

On Sat, Jun 02, 2012 at 03:59:19PM +0200, David Kastrup wrote:
> tdanielsmusic@googlemail.com writes:
> 
> > On 2012/06/02 09:56:57, dak wrote:
> >
> >> Can you point to a coding standard or rationale for LilyPond
> >> regarding only using @ref?
> >
> > Yes.
> >
> > CG 5.4.2: To create links, use @ref{} if the link is within the same
> > manual.
> >
> > And CG 5.3.6 Cross references, which gives a list of the commands to be
> > used in LilyPond documents.
> 
> It does not say _not_ to use other constructs.

That was implied.  Texinfo is confusing enough for most people who
begin working on the docs; just stick with @ref{}.

- Graham

[Keith, 2012-06-02 19:10:32]

On Sat, 02 Jun 2012 01:09:37 -0700, <dak@gnu.org> wrote:

> On 2012/06/02 07:28:37, dak wrote:
>
> It would seem that _trailing_ <> are not really something we should
> lightly suggest since it is unknown what their articulations will
> attach themselves to.
>

I suggested it weightily.
The notations attached to <> are engraved as if they were attached to a note
starting at the musical moment of the empty chord.

When I'm writing a decrescendo at the first beat of a measure, for example, I
know that LilyPond joins it with the next dynamic if there is one, but stops the
hairpin at the barline if I end it with \!.  That's the right thing to do, and
the docs told me how LilyPond does it.  When the note or rest that would take
the \! is separated by a double bar, key change, comments, etc., I happily type
s1*0\!, or <>\!, before the double bar, etc., and get the same correct output.

http://www.google.com/search?q="s1*0"+site:mutopiaproject.org
--
Keith

[Keith, 2012-06-02 19:29:26]

So now I'm just toying with David.

http://codereview.appspot.com/6248080/diff/23001/Documentation/notation/simul...
File Documentation/notation/simultaneous.itely (right):

http://codereview.appspot.com/6248080/diff/23001/Documentation/notation/simul...
Documentation/notation/simultaneous.itely:84: A chord acts merely as a container
for its notes, its articulations and
I think I'll make a more extensive change proposal here instead of an added
section.

http://codereview.appspot.com/6248080/diff/23001/Documentation/notation/simul...
Documentation/notation/simultaneous.itely:94: \repeat unfold 4 { c4 e }  c1\f
That example gives me a headache.  s1*0 will work just fine: you already have an
explicit duration on c4 .  If the crescendo should end on the last note, you
would either cut the repeat short by one, or write
{ \grace { g8[( a b] }
  << { s4*7 ) \p \< -. -\markup \italic "sempre staccato" s4\! }
     \repeat unfold 4 { c4 e } >> c1\f }

But I think the whole thing is too clever for the notation manual.  The rather
contrived ways of avoiding to spell out first/last iterations complicate things
rather than simplify them.

[dak, 2012-06-02 19:42:52]

"Keith OHara" <k-ohara5a5a@oco.net> writes:

> On Sat, 02 Jun 2012 01:09:37 -0700, <dak@gnu.org> wrote:
>
>> On 2012/06/02 07:28:37, dak wrote:
>>
>> It would seem that _trailing_ <> are not really something we should
>> lightly suggest since it is unknown what their articulations will
>> attach themselves to.
>>
>
> I suggested it weightily.
> The notations attached to <> are engraved as if they were attached to
> a note starting at the musical moment of the empty chord.
>
> When I'm writing a decrescendo at the first beat of a measure, for
> example, I know that LilyPond joins it with the next dynamic if there
> is one, but stops the hairpin at the barline if I end it with \!.

I have no idea what you mean by "it", and _where_ you plan to place \!.
The example wrote <>\! (and since there was no \bar "|." following, it
is reasonable to expect this as an excerpt from continuing music), and
if the next note starts with a dynamic, the "smorz." will merge into
that dynamic which is not wanted for.

> That's the right thing to do, and the docs told me how LilyPond does
> it.  When the note or rest that would take the \! is separated by a
> double bar, key change, comments, etc., I happily type s1*0\!, or
> <>\!, before the double bar, etc., and get the same correct output.

No, the output is not correct.  Have you even tried the examples I gave?

-- 
David Kastrup

[dak, 2012-06-03 12:53:24]

http://codereview.appspot.com/6248080/diff/23001/Documentation/notation/simul...
File Documentation/notation/simultaneous.itely (right):

http://codereview.appspot.com/6248080/diff/23001/Documentation/notation/simul...
Documentation/notation/simultaneous.itely:94: \repeat unfold 4 { c4 e }  c1\f
On 2012/06/02 19:29:26, Keith wrote:
> That example gives me a headache.

Compared to yours?  Your proposal was a compressed bunch of symbol shortcuts,
the kind that is controversal.  You now introduce a complication "if the
crescendo should end on the last note" that nobody has asked for and give an
example using simultaneous music which is going to be introduced later in the
notation manual.

Then you come back with "s1*0 will work just fine:".  I don't know how often I
have to repeat myself: this patch is not supposed to replace s1*0 with <>.  It
is supposed to introduce and explain <> at a basic level and put it into context
with << >> which also has been explained insufficiently so far.

If you are unable to focus on anything but s1*0, I'll need to create a separate
issue for discussing this patch, even though getting a sane explanation for <>
and <<>> is part of paving the ground for tackling 2522, by making it possible
to exchange a suggestion of one reasonably documented behavior with a different
reasonably documented behavior.

Because whatever choice we make, it should not be based on wanting to hide the
undocumented truth.

The truth is that there are cases where s1*0 works just as well as <>, and
others where it doesn't.  I will not construct more contrived examples just to
be able to make a better case for <> instead of s1*0.  That's a separate issue.

[Keith, 2012-06-04 04:10:55]

lgtm

http://codereview.appspot.com/6248080/diff/23001/Documentation/notation/simul...
File Documentation/notation/simultaneous.itely (right):

http://codereview.appspot.com/6248080/diff/23001/Documentation/notation/simul...
Documentation/notation/simultaneous.itely:94: \repeat unfold 4 { c4 e }  c1\f
On 2012/06/03 12:53:24, dak wrote:
> On 2012/06/02 19:29:26, Keith wrote:
> > That example gives me a headache.
> Compared to yours? 

I think either yours or mine would be fine, actually. They are pretty similar. 
That's why I copied your comment on my similar suggestion
http://codereview.appspot.com/6197068/diff2/1:10002/Documentation/notation/si...
and pasted it here.

[dak, 2012-06-04 09:51:18]

On 2012/06/04 04:10:55, Keith wrote:
> lgtm
> 
>
http://codereview.appspot.com/6248080/diff/23001/Documentation/notation/simul...
> File Documentation/notation/simultaneous.itely (right):
> 
>
http://codereview.appspot.com/6248080/diff/23001/Documentation/notation/simul...
> Documentation/notation/simultaneous.itely:94: \repeat unfold 4 { c4 e }  c1\f
> On 2012/06/03 12:53:24, dak wrote:
> > On 2012/06/02 19:29:26, Keith wrote:
> > > That example gives me a headache.
> > Compared to yours? 
> 
> I think either yours or mine would be fine, actually. They are pretty similar.

> That's why I copied your comment on my similar suggestion
>
http://codereview.appspot.com/6197068/diff2/1:10002/Documentation/notation/si...
> and pasted it here.

In either case, we have the problem that we need to illustrate putting something
on a music construct "not under our control".  I like the ending slur best for
that purpose since it does not have the "tamper with the first iteration"
flavor.  Putting a markup up is also somewhat in that style, while demonstrating
a "standalone" post-event rather than just a spanner end.  The staccato point is
one step further.

The music construct "not under our control" has the disadvantage that pretty
much everything we can bring up here is beyond the scope already discussed in
the current section.  And in the context of a small example, we'll always have
the "why not just write it out?" question.

Perhaps a simple music variable is a construct that is easier for the unwary
reader to take in and interpret without knowing its impact.  But to not trigger
the "why not just write it out?" question, its content likely should be more
complex than what I put in the repeat.

In contrast to your example, I tried using fewer symbol constructs to reduce the
"Is this Perl?" effect, and I decided not to put an example for putting an
articulation at the _end_ of a sequence, where it will likely combine with the
next note event.

I am not happy with the complexity we show here, but it is pretty much
unavoidable since _this_ is the place where people will look for the respective
information regarding chords, and the simultaneous music section is where they
will look for simultaneousness (so the example I put there regarding
rearrangement of musical material contains both <> as well as s with a non-zero
duration).

So yes: I made a number of choices and tradeoffs that are a judgment call.  And
I am not overly enthused about them.  But I don't see alternatives (including
changing nothing) right now that I see as an improvement.

[Graham Percival, 2012-06-04 14:50:54]

LGTM, pending a serious discussion of this stuff in GLISS.

http://codereview.appspot.com/6248080/diff/23001/Documentation/notation/simul...
File Documentation/notation/simultaneous.itely (right):

http://codereview.appspot.com/6248080/diff/23001/Documentation/notation/simul...
Documentation/notation/simultaneous.itely:263: rhythms; but attempts to attach
notes with different durations to
should be a comma here, not a semicolon.

[dak, 2012-06-04 15:24:20]

We'll likely take months to get the documentation connected with this delicate
issue into a state where it would empower the gentle reader to make an educated
choice himself.

http://codereview.appspot.com/6248080/diff/23001/Documentation/notation/simul...
File Documentation/notation/simultaneous.itely (right):

http://codereview.appspot.com/6248080/diff/23001/Documentation/notation/simul...
Documentation/notation/simultaneous.itely:263: rhythms; but attempts to attach
notes with different durations to
On 2012/06/04 14:50:54, Graham Percival wrote:
> should be a comma here, not a semicolon.

Well, we have two separate complete sentences, and joined with a comma the
reader is easily confused into reading "attempts" as a verb, even though
admittedly it would be singular and thus not a complete match to "the
simultaneous sections".

To me this suggests using a semicolon (or reword everything, but then I am lazy)
in order to save the reader from backtracking.

Obviously, I'll let myself be overruled by native speakers if this reasoning is
considered wrong.

[kieren_macmillan_sympatico.ca, 2012-06-04 15:39:10]

Hi David (et al.),

>> should be a comma here, not a semicolon.
> 
> Well, we have two separate complete sentences, and joined with a comma
> the reader is easily confused into reading "attempts" as a verb, even
> though admittedly it would be singular and thus not a complete match to
> "the simultaneous sections".
> 
> To me this suggests using a semicolon (or reword everything, but then I
> am lazy) in order to save the reader from backtracking.

I would say comma if the "but" is included, semicolon if the "but" is excluded.

Just my 2¢.
Kieren.

[dak, 2012-06-04 15:53:03]

On 2012/06/04 15:39:10, kieren_macmillan_sympatico.ca wrote:
> Hi David (et al.),
> 
> >> should be a comma here, not a semicolon.
> > 
> > Well, we have two separate complete sentences, and joined with a comma
> > the reader is easily confused into reading "attempts" as a verb, even
> > though admittedly it would be singular and thus not a complete match to
> > "the simultaneous sections".
> > 
> > To me this suggests using a semicolon (or reword everything, but then I
> > am lazy) in order to save the reader from backtracking.
> 
> I would say comma if the "but" is included, semicolon if the "but" is
excluded.

I'll change this on commit but not upload a separate patch for review.

[Graham Percival, 2012-06-04 16:00:14]

On Mon, Jun 04, 2012 at 11:39:05AM -0400, Kieren MacMillan wrote:
> Hi David (et al.),
> 
> > Well, we have two separate complete sentences, and joined with a comma
> > the reader is easily confused into reading "attempts" as a verb, even
> > though admittedly it would be singular and thus not a complete match to
> > "the simultaneous sections".
> 
> I would say comma if the "but" is included, semicolon if the "but" is
excluded.

Exactly.  I have no clue why (I never learned grammar), but either
of those options are how I'd expect to read it.  Or maybe change
it to ", but any attempts".

- Graham

[dak, 2012-06-04 16:08:58]

On 2012/06/04 16:00:14, Graham Percival wrote:
> 
> Exactly.  I have no clue why (I never learned grammar), but either
> of those options are how I'd expect to read it.  Or maybe change
> it to ", but any attempts".

That sounds like the best option grammatically, but it lends an absolute flavor
to a statement that can't be supported by evidence.  LilyPond will not deliver
an error, at best a warning, and the results may be inconsistent.  Thus the
construct is best avoided for now (even though it is an obvious contender for
"string chords" once it does work consistently), but "but any attempts" would
not be really supported by facts.

I'll leave this at a comma.  That was what was there before, and good grief am I
sorry that I tampered with it.

[dak, 2012-06-05 12:26:51]

On 2012/06/04 14:50:54, Graham Percival wrote:

> LGTM, pending a serious discussion of this stuff in GLISS.

The topic of GLISS is not how useful we allow the documentation for existing
syntax and functionality to get.  According to its acronym, it is about
standardizing syntax, not its documentation.  So I don't see the point of
invoking its name here.

GLISS might _obsolete_ what we are talking about here, but in the mean time,
useful documentation is nothing we should try our best to avoid.