2013/10/30 David Kastrup <d...@gnu.org>: > Also debugging involves > analyzing the internal data and control flow of a program rather than > its output.
But this is just what some of these features are about! They display the internal data so that the user may analyze it: 1) display-control-points. The output is the slur, i.e. the bezier curve. Control-points are internal data. Displaying control points shows the user the internal data to answer the question "why this slur is so ugly?". 2) coloring voices. It allows to answer a question "why this note has its stem in a wrong direction?" by displaying internal data, i.e. voicing info. (note that without this all you see is just the result - a stem placed in some way, without the "why"). 3) skylines: answers the question "why these objects are so far away/so close?" by showing how lilypond thinks about them. 4) annotate-spacing: "why there is so much/so little space here?" -> "ah, this padding value is too big/small" 5) paper-columns: shows internal information that can answer the question "why this horizontal spacing is so awful?" most of the "debug options" work by showing the user some internal data. >> When we get drag-editing etc. in the music view then we'd certainly >> change the name to something like "Advanced mode". >> >> Currently I think "Debug" suits best. > > I don't. Debugging, like its name suggests, involves the detection and > removal of bugs. What you listed in this category, however, is mainly > intended to help with _tweaking_ parameters rather than finding and > fixing the cause of errant behavior. Note that what we're talking about here is not debugging lilypond code, but debugging LilyPond's layout decisions, by seeing how they are made. best, Janek _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
