Re: convert-ly rules: word boundaries

[Carl D. Sorensen]

On 7/8/09 8:41 AM, "John Mandereau" <address@hidden> wrote:

> 009/7/7 Graham Percival <address@hidden>:
>> I'm not, but almost all updates are in the form
>>  \\oldCommand -> \\newCommand
>> 
>> I suppose that somebody might have tried to speed up convert-ly
>> processing by doing
>>  \\old -> \\new
>> and leaving the "Command" out (thereby using one rule, instead of
>> two rules), but this seems a bit far-fetched.
> 
> IIRC there are some cases where this has actually been done, so all
> must be checked if you rewrite all rules.
> 
> 
>>> If we go for checking every old rule, this job must be split
>>> between several people as it is quite huge:
>> 
>> Not worth it.  The users have spoken quite clearly: they don't
>> care about convert-ly.  (since nobody has volunteered to help with
>> it, and it's an easy thing to do)
>> 
>> I'd just like to fix that one area, plus any new items.
> 
> I'm not sure what you mean; do you expect somebody to quickly add word
> boundaries in all rules in the near future, without checking details
> exposed in this thread, at the risk of breaking working rules?

I don't think that's what Graham means.  The only reason to go back would be
if we find that some rules are broken (which we found for a specific case;
but the same mechanism would apply to lots of rules.  I could write a .ly
file that broke lots of rules if I wanted to take the time to do it; I
don't.)

I think he means that it would be nice to have a function defined in
convert-ly that would allow us to make a robust substitution of

\oldCommandName -> \newCommandName

without having to 

a) handle escaping the \
b) write a proper check to make sure we only get \oldCommandName and not
\oldCommandNameWithAddedWords

Such a function would ease the writing of *new* rules, which is what I think
Graham's main emphasis is.

I believe that it's clearly *not* worth it to fix old rules; there is *no*
benefit to fixing old rules if they're not breaking.  If they do break, we
can fix them at that time, when there is a benefit.

But writing such a function would not only prevent writing broken rules, it
would also save time writing new rules in the future, because the syntax
would be predefined.  So I believe it's worth doing that, even though I
haven't yet volunteered.

Thanks,

Carl