Re: GSoC update; Q's about final/draft modes, and triggering footnotes

[Jeffery Shivers]

For greater flexibility, would it be feasible to allow users to create and name any number of their own modes (rather than having two "hard-coded")?

​ 

Just to put my two cents in, I ​had thought about that as well and almost suggested it in the OP. If a single project could employ certain settings in various modes that aren't necessarily *not* final, for instance, and OLL could help easily navigate those modes, it would certainly be an advantage to using OLL in general. :-)

On Sat, Jul 2, 2016 at 9:34 PM, Jeffery Shivers <address@hidden> wrote:

I'd appreciate any thoughts on the following syntax for implementing footnotes with annotations:

\criticalRemark \with {

    message = "my annotation"

} #'(1 . 2) "my footnote" Slur a4_\the-footnote-hook ( ...

vs.

\criticalRemark \with {

    message = "my annotation"

    footnote-offset = '(1 . 2)

    footnote-text = "my footnote"

} Slur a4_\the-footnote-hook ( ...

vs. either of the above *without* the need for the footnote hook at all. I'm not totally sure how easy/possible it would be to automate the footnote by the presence of offset/text arguments, but I certainly think it would be work trying. Of course, I can see why taking away that need for a hook could also be considered somewhat intrusive of the package, so opinions *against* that would be good to hear.

In the first example, the offset and text arguments would be optional. And of course anything in the annotation properties list (like footnote-offset/text in the second example) are always optional, except for message, I think.

Thanks!

jeffery

On Wed, Jun 29, 2016 at 11:40 PM, Paul <address@hidden> wrote:

On 06/29/2016 10:03 AM, Urs Liska wrote:

Implementation-wise it is basically nothing to add another mode by simply allowing additional values for the "mode" option. Packages can also quite easily implement that by extending the conditionals in their functions to respond to more than two modes. However, to be useful this must be discussed rather on the conceptual side, i.e. what kind of mode would make sense and how to propagate that through different packages (doesn't make much sense to have a mode that doesn't do much). So, this aspect is where this discussion should be done. FWIW, just creating an arbitrary option and configuring your personal files to do some configuration based on that option might as well provide everything you asked for, without even touching the openLilyLib packages themselves. HTH Urs

Ah, ok, I see.  In that case, please disregard my thought.

Cheers,

-Paul

_______________________________________________
lilypond-user mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/lilypond-user