>> Exactly this is not possible, because there exists only a single,
>> global property called `spacing-pair`, which consequently has a
>> single, global description.
>>
>> In other words, the auto-generated documentation sees that an
>> interface uses `spacing-pair`, and it shows its description.
>
> Maybe the comment about the MultiMeasureRest should become a Snippet
> instead.
Maybe, yes, and the property description is linking to that. It would
also shorten the description, which is beneficial in general.
>> IIRC, a suggestion in the mentioned thread is to make the property
>> description displayed for a given grob show which interfaces it is
>> part of, for example
>>
>> ```
>> ‘spacing-pair’ (pair)
>> interface(s):
>> centered-spanner-interface, multi-measure-interface
>
> Yes, but spacing-pair isn't part of the multi-measure-interface.
> Unless that's something that's being developed.
A typo, sorry. I meant `multi-measure-rest-interface`.
>> default value:
>> '(break-alignment . break-alignment)
>>
>
> There's a problem there, too, in that the default value depends on the grob.
>
> In MeasureSpanner, the default value is (staff-bar . staff-bar)
>
> In PercentRepeat, it's (break-alignment . staff-bar)
I don't see a problem here. For grob `foo`, it is completely
irrelevant whether property `bar` is part of interface `xxx` or `yyy`.
You access it as `foo.bar`. Consequently, it is just a courtesy to
the reader to mention which interface a property is part of.
Maybe a grob description on the page showing the available default
properties for `MeasureSpanner` could be displayed as
```
‘spacing-pair’ (pair)
relevant interface:
centered-spanner-interface
default value:
'(break-alignment . break-alignment)
A pair of alignment symbols which set an object's spacing
relative to its left and right ‘BreakAlignment’s.
For example, a ‘MultiMeasureRest’ will ignore prefatory items
at its bounds (i.e., clefs, key signatures and time
signatures) using the following override:
\override MultiMeasureRest.spacing-pair =
#'(staff-bar . staff-bar)
```
>>> And there's actually precedent, in that left-handed chord diagrams
>>> (FretBoards) are supported by Lilypond.
>>
>> Well, this makes sense, because they are displayed differently.
>
> Also, there's a grob named StrokeFinger. It's not named
> RightHandFinger.
This is admittedly an inconsistency and could be fixed. However, I'm
not sure whether it is worth the cost: Renaming stuff forces all
LilyPond users to re-learn commands that exist since a long time.
Normally, we only do this only if there is confusing terminology (see
the parallel thread about musical duration, moments, etc.) In this
case, however, it will IMHO suffice to mention that LilyPond uses the
term 'right hand' for the strumming hand.
A user can also very easily define new commands that better fits the
intended purpose, for example,
```
strummingHandFinger = \rightHandFinger
```
Werner
