On 10/24/10 8:17 PM, "Valentin Villenave" <[email protected]> wrote:
> On Mon, Oct 25, 2010 at 3:57 AM, <[email protected]> wrote: >> Update the \version string in all of these files! > > Well, I was reluctant to put a minor version number. Do you think > putting "2.14.0" would be okay? > >> Then, the argument to your music function would not be a string, but >> rather a symbol: >> >> \language #'italiano > > I did consider it. However, I have three reasons not to use symbols: > - from a user perspective, typing "italiano" is slightly more > straightforward than typing #'italiano. Remember, this function is > intended for newcomers, who wouldn't even use music variables or > \score blocks, let alone \overrides, boolean or symbols! Well, although your intention is to make it easy for newcomers, that's not (IMO) a good reason to move forward on this. There are lots of other ways to make it easy on newcomers (e.g. a template file that starts with the language statement). For me, the real reason is to get a language selection method that can run in safe mode. > - this also allows me to treat the given argument as case-insensitive. I think this is a reason *not* to use the case-insensitive implementation. LilyPond input *is* case sensitive (r1 is not the same as R1, c4 is not the same as C4). I think we should always be case-sensitive if we're ever case-sensitive. I would prefer to eliminate the case conversion part of the patch. I think that the best thing we can do to be easier is to be consistent. > - last but not least, if we ever do implement the \language command as > a parser token, taking a simple-string argument, then almost no > changes will be needed (if anything, the "foobar" syntax will still > work, but plain \language foobar, without quotes, will also be > possible). This answer is much more compelling to me. \language italiano (like \clef treble) is very consistent. So you've convinced me that a string argument is OK. > > That being said, I can indeed nest all the alists together, without > necessarily using a (symbol?) argument: string->symbol is reliable > enough A new patchset is on its way.. Perfect! > >> That way we don't have to mess with strings and string comparisons, we >> just use symbols. > > Well, I hope I made my point about using strings. I'm pretty hopeful > that string->symbol does a reliable enough of a job to not qualify as > "messy" :-) Yep, it's fine. Thanks, Carl _______________________________________________ lilypond-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/lilypond-devel
