Re: melismaBusyProperties: scheme syntax vs. lily syntax

[Thomas Morley]

2018-07-16 3:14 GMT+02:00 Carl Sorensen <address@hidden>:
>
>
> 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


Hi all,

let me hook in here, refering to the more generic topic of this
thread: "scheme syntax vs. lily syntax"

Meanwhile we have several possibilities where naked scheme-syntax can
be done by more readable and (hopefully) more userfriendly ly-syntax.
Things like dotted/comma-separated lists, etc.
Several macros were introduced as well, `make-engraver` for example.

All very nice. Most of the time.

Though, I remember at least one instance where `make-engraver' failed
for a very special use-case.
Then I tried the scheme-list-syntax for engravers and found it worked.
Asking on the list, David K confirmed a certain limitation in
`make-engraver`.
Meanwhile we had eliminated the scheme-list-syntax for engravers from
our source completely, without having stored some examples of old
list-syntax-engravers I would have been lost.

Probably other problems with ly-syntax (replacing scheme-syntax) and
macros may occur, _if_ they are attempted to be used for something
they were not designed for.

So I think we should explain/demonstrate somewhere what these
syntax/macros are supposed to do/replace in order to give people
wanting to change/extent/further develop them some more basic hints.

As an example:

foo = 2,4,8
\void \displayScheme \foo
=> (list 2 4 8)

Would the Extanding Manual be an appropriate place?


Cheers,
  Harm