Re: melismaBusyProperties: scheme syntax vs. lily syntax

[Carl Sorensen]

On 7/15/18, 6:53 PM, "Simon Albrecht" <address@hidden> wrote:

    On 16.07.2018 02:51, Carl Sorensen wrote:
    >
    > On 7/15/18, 3:29 PM, "lilypond-devel on behalf of David Kastrup" 
<address@hidden on behalf of address@hidden> wrote:
    >
    >      Simon Albrecht <address@hidden> writes:
    >      
    >      > Hello everybody,
    >      >
    >      > I just noticed that it’s possible to use the LilyPond symbol 
list/key
    >      > list syntax when setting melismaBusyProperties. However, the doc
    >      > string reads
    >      >
    >      > "A list of properties (symbols) to determine whether a melisma is 
playing.
    >      > Setting this property will influence how lyrics are aligned to 
notes.
    >      > For example, if set to @code{'(melismaBusy beamMelismaBusy)},
    >      > only manual melismata and manual beams are considered.
    >      > Possible values include @code{melismaBusy}, @code{slurMelismaBusy},
    >      > @code{tieMelismaBusy}, and @code{beamMelismaBusy}."
    >      >
    >      > Would we want to change the first code example to
    >      >
    >      > @code{melismaBusy,beamMelismaBusy}
    >      >
    >      > or otherwise suggest the new syntax?
    >      
    >      Feel free to do so, I think.  It's not really a change of syntax
    >      specifically for melismaBusyProperties so I'd likely not mess with 
the
    >      descriptions when they talk about "symbol list" or whatever.  Instead
    >      I'd just change the examples.
    >
    > I don't think we should change the doc string.  IIUC, the property 
actually is a list. But we can set it using LilyPond syntax, as well as Scheme 
syntax.  So I agree that it should shown in the examples, but the docstring 
should not be changed.
    
    What examples do you mean?

Apparently, there are none. So I guess that if we want to move in this 
direction, we should add a docs tagged snippet that shows the property being 
set.

Or alternatively, we should just leave it as is.

Thanks,

Carl