Re: Why no review on Doc: NR 1.6.2 - Staff Symbol?

[James]

David,

I've not read through your response thoroughly as I have to go out now but I defer to your knowledge and have reverted the check-in in staging.

As I said, there was nothing sinister and my intentions were honourable.

I'll read the thread when I get back later.

Regards

James

On 3 December 2011 14:38, David Kastrup <address@hidden> wrote:

James <address@hidden> writes:

> Nothing sinister about it, and am happy to revert it but don't
> understand why this is bad. Sure the new example is much 'simpler'
> than having  write all the \new Staff { with }, especially when I as a
> LP user want to write single system scores where I would probably
> never ever use \new Staff { \with.

You apparently did not read what I wrote.  The new example _does_ _not_
_work_ in standalone contexts.  It bombs out with an error message.  If
a user tries to use that code, he won't understand why it produces
errors.  Your "simplification" makes the user write _bad_ code, code
bombing out with errors for no apparent reason.  In particular since the
documentation suggests it would work.

The _only_ reason it does not bomb out the documentation build process
is because it is enclosed in

@lilypond[verbatim,quote,relative=2]

which means that lilypond-book will silently wrap a
\relative c'' { ... } around the example without telling the user about
it.  That is nice for avoiding clutter in the docs when we are talking
about constructs belonging inherently inside of a voice anyway.

It is not nice for conceptually top-level constructs like setting up
Staffs and systems.

And anyway, using music overrides instead of context modifications is
_asking_ _for_ _trouble_ here since the overrides take only effect at a
certain _musical_ moment.  And that moment may already be too late for
proper typesetting.

There is no remotely current patch for 1935 registered, certainly not
anything that has even _remotely_ anything to do with this documentation
change.

So I am annoyed that there was not even the slightest chance given for
reviewing a change that is a change to the worse for a number of
reasons.

I am all for making Lilypond simpler to use.  I have been slaving away
on simplifying Lilypond for a long time.  But this documentation change
_lies_ about simplicity.  What is proposed here _will_ _not_ _work_ in
the given form when put into a user document.  Trying to use this will
annoy and frustrate the user.

--
David Kastrup


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

--
--

James