Currently supported options from lilypond-book

jperon / lyluatex

Alternative à lilypond-book pour lualatex

MIT License

58 stars 11 forks source link

Currently supported options from lilypond-book #37

Closed rpspringuel closed 6 years ago

rpspringuel commented 6 years ago

If lyluatex is to be a drop-in replacement for lilypond-book Then the goal should be to support all the lilypond-book music fragment options. This list is intended to keep track of what is currently supported and what is not:

[x] staffsize=ht
[ ] ragged-right
[ ] noragged-right
[ ] line-width
[x] line-width=size\unit
[ ] papersize=string
[ ] notime
[ ] fragment
[x] nofragment
[ ] indent=size\unit
[ ] noindent
[ ] quote
[ ] exampleindent
[ ] relative
[ ] relative=n

There are also the following options which are specifically designed for LilyPond's documentation and thus of lower priority:

[ ] verbatim
[ ] addversion
[ ] texidoc
[ ] doctitle
[ ] nogettext
[ ] printfilename

rpspringuel commented 6 years ago

Based on my reading of the keycommand package, it is not possible to support a keyword which is both boolean (given or not given) and general (given with a value). That is line-width without a value cannot be supported along side line-width=size\unit (similar for relative and relative=n). I'm not so sure about other ways of defining keyword commands (such as keyval or pfgkeys).

uliska commented 6 years ago

@rpspringuel have you ever looked into the (rather new) Github feature of "projects"? Maybe lilypond-book compatibility would be a good candidate for that. The checklist would then become a backlog, with the advantage that each item could become an issue (with assignee, comments etc.).

rpspringuel commented 6 years ago

No, I haven't. I'll look into converting this into one of those now, as it seems like as good a time as any to familiarize myself with the new feature.

rpspringuel commented 6 years ago

Now Project #1

uliska commented 6 years ago

Thank you. I think that's a good way to track this "project". In theory the notes could immediately be changed into issues, but that would unnecessarily clutter the issue tracker. So for now I suggest that in order to comment on notes we edit them but clearly mark the edit as comments.

In general I suggest that we don't try to copy lilypond-book but aim at supporting all of its options. I would discuss the naming of options separately and provide compatibility aliases if necessary. For example, I find the quote name pretty stupid. It's clear where it's coming from, but an indented music example semantically is in no way a "quote".

rpspringuel commented 6 years ago

So for now I suggest that in order to comment on notes we edit them but clearly mark the edit as comments.

The one problem I see here, is that the cards are limited in size. Any issue that really starts to generate discussion will quickly run out of space and require conversion to an Issue anyway in order to continue the discussion.