lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Make several special characters with or without backslash "non-speci


From: David Kastrup
Subject: Re: Make several special characters with or without backslash "non-special" (issue 12432043)
Date: Mon, 05 Aug 2013 14:03:16 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Jan Nieuwenhuizen <address@hidden> writes:

>> LGTM.  Very nice!
>>
>> https://codereview.appspot.com/12432043/
>
> Nice.  Looking at your remarks
>
>    Make tempo range \tempo 20~30 be input as \tempo 20-30 instead
>    Dash is not particularly nice here
>
> I would expect something like \tempo #20 and \tempo #'(20 30); however
> I'm not sure if that would be in scope for this patch, and how much
> we want to expose guile into .ly for normal use?

If you allow a number or a pair, either 20 or 20/30 will be acceptable.
However, we had a discussion about this about a year ago, and there was
a definite lack of enthusiam about using what looks like a fraction
here.  Now one need not go overboard for avoiding Scheme: after all,
\override/\revert only very recently got a non-Scheme input method.

Nevertheless, I don't think that there would be a lot of enthusiasm for
requiring Scheme here.

One drawback I have not mentioned is the accessibility of those symbols
from Scheme.  It turns out that (string->symbol "\\(") cranks out
something like #{\\\(}# in Guile 1 and #{\\x28;}# (which actually seems
wrong) in Guile 2.  So the "straight" input syntax is sort of iffy, but
people usually won't need it.  Just using the string is easier to
remember than working with things like escapedParenOpenSymbol.

There is also a slight inconsistency in that definition/use pairs are

"xxx" = ... called via \xxx
"|" = ... called via |
"\\|" = ... called via \|

So for symbols, the backslash becomes part of the symbol name while it
doesn't for proper words.  Again, this seems natural, but it also means
that symbols like "+" or "-" or "/" or "*" seem rather off limits unless
they get encoded with something more intricate than string->symbol.  Now
"-", "*", "/" are all special in the parser anyway, but one might still
want to keep this in mind.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]