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 <d...@gnu.org> wrote:
> James <pkx1...@gmail.com> 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
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
>
--
--
James
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
