Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reconsider \editionMod interface #12

Open
uliska opened this issue May 16, 2016 · 3 comments
Open

reconsider \editionMod interface #12

uliska opened this issue May 16, 2016 · 3 comments
Labels

Comments

@uliska
Copy link
Contributor

uliska commented May 16, 2016

I would like to raise discussion of completely changing the interface to \editionMod, as I find it confusing to have functions with so many unnamed parameters.

I would suggest an approach with named parameters, either optional Scheme parameters or a \with construct (ly:context-mod?). This would make the input more explicit, and it would make it easier to add more options and/or add flexibility. As an example that way one could integrate the addressing by rehearsal mark offsets.

Such an approach would imply more markup overhead, I know. But that could be alleviated by having many parameters default to a value, which could make the code more readable as well.

Something like

\setOption edition-engraver.target-edition test
\setOption edition-engraver.target sing.with.bach.along

\editionMod \with {
  moment = #'(2 0/4)
  mod = { \once \override NoteHead.color = #red }
}
\editionMod \with {
  hook = Blupp
  moment = #6/4
  mod = ...
}

This is not thought through at all yet, just meant as a start for discussion. This approach will generally produce more code but I think that code will be more readable, and it will be more natural to write.

@uliska
Copy link
Contributor Author

uliska commented May 16, 2016

If we agree on something I could give it a try (although I don't know if I manage to do so. Maybe I could be challenged to do so before having my presentation at the MEC)

@jpvoigt
Copy link
Collaborator

jpvoigt commented May 16, 2016

I understand your concerns about the unnamed parameters. But I would only add this named one-parameter-blob as another option. For now I think, we need another function, because I doubt that the optional parameters can't deal with one blob or several parms.
But perhaps we find another solution.

@uliska
Copy link
Contributor Author

uliska commented May 16, 2016

I would in any case develop it as another function. And if it should turn out to be useful or even superior I would then first "deprecate" the old function.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants