David Kastrup wrote Tuesday, May 08, 2012 11:06 AM

> "Trevor Daniels" <t.daniels@tred...> writes:
>
>> Keith OHara wrote Tuesday, May 08, 2012 3:48 AM
>>
>>> I suggest we mention that <> takes no time in NR 1.5.1 Chorded
>>> Notes, but avoid it in the examples.
>>>
>>> Most of the visible uses of s1*0 in the docs were instigated by me,
>>> so I see how to avoid them.
>>
>> This seems like a sensible way forward.  Let's take it a
>> step at a time:
>>
>> 1. Raise a bug report to highlight the problems of s1*0,
>> giving the <> workaround.  That seems standard procedure
>> for the bug squad - a problem has been identified and a
>> workaround suggested.  David - thanks for alerting us to this!
>
> There is no bug with s1*0.

I didn't say there was.  But there is a problem with the documentation.
You've identified it, and it should be raised as an issue.  As you say:

> Which is the reason s1*0 is an accident waiting to happen.  It takes a
> programmer to understand its numerous implications.

The documentation should aim to minimise the likelihood of this
happening.  It is doesn't it's defective and should be improved.

> The simple rule
> "never forget an explicit duration for the next element or things will
> blow up" is nice, but if s1*0 is used for the last element in a
> sequence, it is not easy to do always.

That sounds like a good warning to add.

>> 2. Document the semantics of <> in NR 1.5.1.  Does anyone
>> dissent from this?  Ian has already provided a reasonable
>> first draft.
>
> It is not complete without including an explanation why that construct
> is being avoided in the rest of the manual for the sake of more complex,
> error-prone and cumbersome code.

No, but it's a sensible first step.  It is an improvement in itself.  The
rest
follows in step 3.

>> 3. Look at the individual uses of s1*0 and see first if its use can be
>> avoided.  We can discuss each of these individually,
>> considering the relative merits of using alternative approaches (if
>> any) or using <>.
>
> The goal being to avoid the impression that there is a working and
> simple approach for letting postevents happen at some time without
> requiring a note or rest, instead using parallel music and spacer rests,
> or a number of other constructs more or less suited to different
> situations, instead of a single, existing, simple tool.

No.  Didn't I list <> as an possibility?  The goal being to find the
consensus solution.  You have a firm opinion about what is best;
others disagree.  But this isn't David's project (or Graham's either);
it's a community project.  People downing tools or putting on coats
or otherwise resorting to extortion doesn't help.

I should have added a 4th point to my list:

4. Defer discussion of z or other alternatives to <> until GLISS.

Trevor


_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu....
https://lists.gnu.org/mailman/listinfo/lilypond-devel