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
_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
