Aaron Hill <lilyp...@hillvisions.com> writes: > On 2018-06-07 07:58, David Kastrup wrote: >> Aaron Hill <lilyp...@hillvisions.com> writes: >> >>> On 2018-06-07 06:34, Aaron Hill wrote: >>>> Hi David, >>>> >>>> Correct me if I am wrong, but the second definition is ***not*** >>>> usable as a >>>> function. That is, it cannot accept a parameter for customizing the >>>> markup. Unless `\etc` is something magical that is undocumented, the >>>> resulting `\doubleBox` would have to be a complete idea. >>> >>> (See ***correction*** above.) >>> >>> I hate email sometimes... No ability to edit when you make a dumb >>> typing mistake. Sorry. >> >> I don't understand what you consider "not a function" though. It is a >> function with constrained form, but a function nevertheless since it >> takes a text/markup parameter. > > There are likely many pedants who would say that functions strictly > have non-zero arity, but that is neither here nor there.
So? It has arity one. > The snippet you mentioned does not work as-is on 2.19.81, so I was > curious if there was something new going on with how to define > functions. It will in 2.21.0. > As I originally suspected `\etc` was nothing more than a placeholder > for other, actual markup, your suggested definition of `\doubleBox` > ultimately becomes a fixed, parameter-less construct. Uh, isn't that the definition of a function's parameter? > That is, you could not say `c\doubleBox foo`, which is what Urs was > trying to achieve. Uh, you can in current master. > Is there something potentially unsound about using > define-event-function to that end? No. But if Urs is using current master anyway... -- David Kastrup _______________________________________________ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
