Han-Wen Nienhuys wrote:
[EMAIL PROTECTED] writes:
May I ask for the reason of this change. I think it's very convenient to have this kind of shortcut, especially for scripts, where two different layout objects are involved, depending on the type of script.
I deemed it unnecessary since there is already very convenient shorthand (_ and ^) for tuning individual objects. If many objects need to be tuned, the appropriate \override takes little more work than \scriptUp/Down
I think the main problem is not the work to enter the code, but rather the work to find out how to do it. I think the shortcuts help both for newcomers who haven't yet learned how to set properties, somewhat experienced people who still have problems to always find the relevant grob, property and value and oldboys like me who know where to look for all the relevant information but find it easier to remember the names of the shortcuts than the exact name of every grob and property.
If we concentrate on the two first categories, I think these precooked macros can also be a good pedagogical tool, especially if we include the full definitions in the manual, as they are good examples both of how to do the actual setting but also of how you can defined your own shortcuts.
The decision isn't final, but I would like to phase out the shortcuts in ly/property-init.ly gradually, replacing them with more generic mechanisms.
If you definitely don't want to pollute the global name space with predefined macros, I think you shouldn't remove any such macro from property-init.ly without including it in the manual. For example, you could add something like
"The following macros may be convenient, to set the direction of articulations and textual indications in the score:
scriptUp = {
\override TextScript #'direction = #1
\override Script #'direction = #1
}
scriptDown = {
\override TextScript #'direction = #-1
\override Script #'direction = #-1
}
scriptBoth = {
\revert TextScript #'direction
\revert Script #'direction
}"
As I said above, I actually think it would be a good idea to add it even if we don't remove the definitions from property-init.ly.
/Mats
_______________________________________________ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
