Re: convert-ly rule

[address@hidden]

On 13 mars 2013, at 11:00, David Kastrup <address@hidden> wrote:

> "address@hidden" <address@hidden> writes:
> 
>> Hey all,
>> 
>> I'm not too good at writing convert-ly rules.  Is there a model I can
>> use for replacing a property with another?  Specifically, I'd like to
>> write a patch changing:
>> 
>> TupletBracket.staff-padding
>> 
>> to:
>> 
>> TupletBracket.bracket-staff-padding
>> 
>> as one cannot currently use the side position interface callbacks on
>> TupletBrackets because staff-padding in the tuplet-bracket-interface
>> works differently than staff-padding in the side-position-interface.
>> 
>> Lemme know if anyone has a good solution.  Otherwise I'll hack away...
> 
> I am not happy about name proliferation.

Me neither.

> On the other hand, I don't
> know how something like
> 
> TupletBracket.tuplet-bracket-interface.staff-padding
> 
> could sensibly be implemented

Instead of using dots, you use another symbol like @. Then, the symbol is 
parsed into the before and after @. If there is no before, the property applies 
to all interfaces implementing after.

> and it would be pretty much impossible to
> know reliably when and when not a further qualification would be
> required to keep all callbacks properly informed.

It's true that this is a mess for override and revert...

> 
> It might also be possible to let a callback check for the existing grob
> interfaces in possible cases of contention and only use the respective
> value if the grob had the proper interface.
> 
> So you'd have a callback that only looked at staff-padding in the
> tuplet-bracking-interface manner if the grob had that interface, and
> would look at it in the side-position-interface manner only if the grob
> had _that_ interface.
> 
> That would require giving grobs a set of interfaces that interpret any
> given property only in one manner.

Then that would mean that the tuplet bracket could never use side position 
interface and vice versa.

> 
> That would work without convert-ly rules and a larger namespace set.  It
> would also mean that you would look at the interfaces of a grob in the
> documentation to decide which values were supported.  That there are
> some callbacks able to interpret the _same_ property differently
> depending on the interfaces of a given grob, in contrast, is an
> implementation detail buried deep enough to probably not appear
> disturbing to a user.
> 

This is the current state of things minus the verification step.
We are admittedly only talking about the world of overrides for now, but it 
seems that certain kludges exist in the code base to work around this problem 
(like for minimum-length). There are also documentation bugs, as these 
properties do multiple things but only have doc strings for a single case. In 
terms of extensibility, we should have a way to deal with the creation of new 
properties and the managing of old ones to avoid this sorta problem.

> -- 
> David Kastrup
> 
> 
> _______________________________________________
> lilypond-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-devel