Re: minimal examples

[Mats Bengtsson]

Hans Aberg wrote:
> The problem is that a user which does not know anything about actual 
> LilyPond debugging is in a rather poor position doing the actual 
> reduction you want to see unless you tell how. This is normal in bug 
> reporting. I think you need to have at least one developer accessible 
> to have a look at the bug reports before filing; this way others will 
> learn, and the long term developer effort will be reduced.
That's what Graham is trying to do. He voluntarily does a huge job on 
both this task
and the document revisions, all on his spare time. Please don't feel 
insulted by his
comments on non-minimal examples. The next time you submit a bug report, I'm
sure you will spend a few more minutes yourself first. Apart from 
simplifying the
task for Graham and the LilyPond hackers, another main advantage of this
exercise is that the process of reducing an example down to a few lines 
often
teaches you a lot about how LilyPond works and sometimes you figure out that
it wasn't a bug at all, but just a misunderstanding from your own side. 
Also,
the things you learned during the process will often be very useful when 
you
typeset some other score in the future. So, Grahams picky comments are 
actually
also part of a pedagogical effort to improve the LilyPond competence of 
every
user (perhaps unintentionally).
Anyway, the main point is that there's a lack of developers resources so 
it's a
great thing that the main hackers don't have to spend their time sifting 
through
the bug-lilypond mailing list to figure out what is a real bug and was 
isn't.
> > All the bug reporting process is described on
> > http://lilypond.org/web/devel/participating/bugs
> > Granted, it's not very easy to find, but it does exist.
>
> If you want people to follow this, simplify it as much as possible. 
> For example, it would be good if you could make sure the "\paper{ 
> ragged-right=##t }" is not needed, somehow (a default in LilyPond?). 
> Things that users can't understand why it should be there, no matter 
> how useful it is to developers, is likely to drop out anyway in the 
> user's bug reports.
Sure, but if you take the effort to copy/paste that line from the 
instructions, you will
very quickly notice the difference and realize that it was indeed 
useful, not only for
the specific bug report (where Graham easily can add that line himself) 
but also when
you do your own experiments to learn more about LilyPond.

Actually, some 10 years ago in the very first pre-releases of LilyPond, 
there was
the special feature that if you changed the file suffix from .ly to .sly 
(or whatever, I
don't remember exactly), then LilyPond added some standard code around the
contents of the file, similarly to what you request above. However, this 
feature was
removed a long time ago and I was one of the people who advocated this 
change,
since it was a feature that's not useful in any real-world typesetting, 
just for doing
small toy examples and that it could more confusion than help.
Now that it's no longer necessary to include an explicit \score{...} 
block, for example,
we are almost back at the same situation that was previously offered by 
the .sly file
suffix. As has been discussed on the mailing lists, this is not 
necessarily a good thing,
since once you really need to explicitly specify a \score block, then 
you have never
learned to do it and some the things that LilyPond does by default is 
fairly non-
intuitive. However, this is another discussion.


    /Mats