Re: GSoC update; Q's about final/draft modes, and triggering footnotes
Absolutely - in fact, using the presence of offset to indicate *I'm a footnote* was just a practical solution since I am sure some projects won't *always* want annotations to become footnotes, and with this check wouldn't need to specify explicitly *when* and *when not*. However, maybe it would be best to go ahead and use a global boolean ((true) annotations always footnotes (regardless of offset), or (false) only when set in each context-mod to true (which could still be taken from offset's presence to avoid an additional/separate indication - at least while automatically-placed offsets don't exist). That may be the more appropriate way to handle it. Hmm, intelligent/automatic footnote offsets - that sure would be nice. On Tue, Jul 5, 2016 at 2:51 AM, Simon Albrecht wrote: > On 05.07.2016 03:31, Jeffery Shivers wrote: > >> Since offset is presumably always going to be used for footnotes, I think >> *that* should be what triggers the footnote. So, inclusion of `offset = >> #'(...)` will tell scholarLY that the annotation is a footnote; otherwise >> it *isn't*. If it's preferred to rather have an explicit boolean (like >> apply-footnote = ##t, or whatever), that could work. But I will say that I >> prefer using something as obvious as offset as a sort of automatic >> indication of footnote-ness. >> > > As long as one _has_ to manually specify the offset, that’s sensible. And > if Lily ever gets clever enough to place the footnote items on her own, it > will be easy enough to change this behaviour, I assume. > > Best, Simon > ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GSoC update; Q's about final/draft modes, and triggering footnotes
On 05.07.2016 03:31, Jeffery Shivers wrote: Since offset is presumably always going to be used for footnotes, I think *that* should be what triggers the footnote. So, inclusion of `offset = #'(...)` will tell scholarLY that the annotation is a footnote; otherwise it *isn't*. If it's preferred to rather have an explicit boolean (like apply-footnote = ##t, or whatever), that could work. But I will say that I prefer using something as obvious as offset as a sort of automatic indication of footnote-ness. As long as one _has_ to manually specify the offset, that’s sensible. And if Lily ever gets clever enough to place the footnote items on her own, it will be easy enough to change this behaviour, I assume. Best, Simon ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GSoC update; Q's about final/draft modes, and triggering footnotes
This footnote feature is now up-and-running, for those who are interested. https://github.com/openlilylib/scholarly/tree/footnotes-feature There is an example doc also: usage-examples/footnote-trigger-test.ly -j On Mon, Jul 4, 2016 at 9:31 PM, Jeffery Shivers wrote: > Now offset and footnote (text) can be set in the properties list. > `footnote = "text"` can be explicitly set and used for the footnote text, > or, if not set, `message = "text"` is assumed to be the footnote text, if > made into a footnote at all. > > \criticalRemark \with { > message = "my message; could be a footnote too" > offset = #'(1 . 1)% tells scholarLY to make a footnote of this > footnote = "this could be a shorter footnote than message, and > will become the footnote if used" > } ... > > Since offset is presumably always going to be used for footnotes, I think > *that* should be what triggers the footnote. So, inclusion of `offset = > #'(...)` will tell scholarLY that the annotation is a footnote; otherwise > it *isn't*. If it's preferred to rather have an explicit boolean (like > apply-footnote = ##t, or whatever), that could work. But I will say that I > prefer using something as obvious as offset as a sort of automatic > indication of footnote-ness. > > -j > > On Sun, Jul 3, 2016 at 11:15 AM, Urs Liska wrote: > >> >> >> Am 03.07.2016 um 14:48 schrieb Simon Albrecht: >> > On 03.07.2016 03:34, Jeffery Shivers 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 ( ... >> > >> > The first is less keystrokes, but the second makes the code so much >> > easier to read, that I prefer it. The keystrokes might be reduced by >> > autocompletion in the editor. >> > >> >> >> >> 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. >> > >> > It would be good to have a possibility of using the message as >> > footnote-text, perhaps triggering the footnote through a boolean then. >> > I would certainly prefer not to need a footnote hook; it seems >> > somewhat redundant from a user’s perspective. >> >> I also have the impression that everything that has to be written >> *outside* the \with {} makes the whole thing rather cluttered (and we >> also have to take into account that we need different syntax for >> \override and \tweak-style annotations). >> So if it's possible to avoid having to do that I think it would be >> definitely preferable. >> >> Urs >> >> >> > >> > Best, Simon >> > >> > ___ >> > lilypond-user mailing list >> > lilypond-user@gnu.org >> > https://lists.gnu.org/mailman/listinfo/lilypond-user >> >> >> ___ >> lilypond-user mailing list >> lilypond-user@gnu.org >> https://lists.gnu.org/mailman/listinfo/lilypond-user >> > > ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GSoC update; Q's about final/draft modes, and triggering footnotes
Now offset and footnote (text) can be set in the properties list. `footnote = "text"` can be explicitly set and used for the footnote text, or, if not set, `message = "text"` is assumed to be the footnote text, if made into a footnote at all. \criticalRemark \with { message = "my message; could be a footnote too" offset = #'(1 . 1)% tells scholarLY to make a footnote of this footnote = "this could be a shorter footnote than message, and will become the footnote if used" } ... Since offset is presumably always going to be used for footnotes, I think *that* should be what triggers the footnote. So, inclusion of `offset = #'(...)` will tell scholarLY that the annotation is a footnote; otherwise it *isn't*. If it's preferred to rather have an explicit boolean (like apply-footnote = ##t, or whatever), that could work. But I will say that I prefer using something as obvious as offset as a sort of automatic indication of footnote-ness. -j On Sun, Jul 3, 2016 at 11:15 AM, Urs Liska wrote: > > > Am 03.07.2016 um 14:48 schrieb Simon Albrecht: > > On 03.07.2016 03:34, Jeffery Shivers 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 ( ... > > > > The first is less keystrokes, but the second makes the code so much > > easier to read, that I prefer it. The keystrokes might be reduced by > > autocompletion in the editor. > > > >> > >> 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. > > > > It would be good to have a possibility of using the message as > > footnote-text, perhaps triggering the footnote through a boolean then. > > I would certainly prefer not to need a footnote hook; it seems > > somewhat redundant from a user’s perspective. > > I also have the impression that everything that has to be written > *outside* the \with {} makes the whole thing rather cluttered (and we > also have to take into account that we need different syntax for > \override and \tweak-style annotations). > So if it's possible to avoid having to do that I think it would be > definitely preferable. > > Urs > > > > > > Best, Simon > > > > ___ > > lilypond-user mailing list > > lilypond-user@gnu.org > > https://lists.gnu.org/mailman/listinfo/lilypond-user > > > ___ > lilypond-user mailing list > lilypond-user@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-user > ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GSoC update; Q's about final/draft modes, and triggering footnotes
Am 03.07.2016 um 14:48 schrieb Simon Albrecht: > On 03.07.2016 03:34, Jeffery Shivers 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 ( ... > > The first is less keystrokes, but the second makes the code so much > easier to read, that I prefer it. The keystrokes might be reduced by > autocompletion in the editor. > >> >> 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. > > It would be good to have a possibility of using the message as > footnote-text, perhaps triggering the footnote through a boolean then. > I would certainly prefer not to need a footnote hook; it seems > somewhat redundant from a user’s perspective. I also have the impression that everything that has to be written *outside* the \with {} makes the whole thing rather cluttered (and we also have to take into account that we need different syntax for \override and \tweak-style annotations). So if it's possible to avoid having to do that I think it would be definitely preferable. Urs > > Best, Simon > > ___ > lilypond-user mailing list > lilypond-user@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GSoC update; Q's about final/draft modes, and triggering footnotes
On 03.07.2016 03:34, Jeffery Shivers 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 ( ... The first is less keystrokes, but the second makes the code so much easier to read, that I prefer it. The keystrokes might be reduced by autocompletion in the editor. 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. It would be good to have a possibility of using the message as footnote-text, perhaps triggering the footnote through a boolean then. I would certainly prefer not to need a footnote hook; it seems somewhat redundant from a user’s perspective. Best, Simon ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GSoC update; Q's about final/draft modes, and triggering footnotes
> > 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 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 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 >> lilypond-user@gnu.org >> https://lists.gnu.org/mailman/listinfo/lilypond-user >> > > ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GSoC update; Q's about final/draft modes, and triggering footnotes
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 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 > lilypond-user@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-user > ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GSoC update; Q's about final/draft modes, and triggering footnotes
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 lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GSoC update; Q's about final/draft modes, and triggering footnotes
> > Both lilypond and LaTeX have steep learning curves One of the conditions of the package , in my mind, is to make its usage possible at the highest level, but configurable at the lowest. LaTeX is such a powerful utility, and in this case should really extend our workflows (and not necessarily further complicate them). It's nearly there, but at this point, for example, \documentclass{article} \usepackage{scholarLY} \begin{document} \annotations{lilypondexportfile.inp} \end{document} will render the entire list (well, virtually; the file paths are a little wonky rn). We've recently added a default stylesheet that is itself used by the package to format the list, but also exemplifies almost all of the macros available for customization. So it's definitely a priority for this to be as practical a resource as possible. Also, we plan to add more export types (such as markdown, and even scheme - which could make compilation possible directly in lilypond), so that the choice of *how* it is implemented is itself available upfront. On Wed, Jun 29, 2016 at 10:03 AM, Urs Liska wrote: > > > Am 29.06.2016 um 15:12 schrieb Paul: > > Hi Jeffrey, > > > > It's good to hear about your progress! Just a thought about modes... > > > > On 06/27/2016 07:50 PM, Jeffery Shivers wrote: > >> ***Final/"draft" Modes*** > >> OpenLilyLib will ideally be used in final/draft/etc. modes in order to > >> toggle between fancy/plain settings, or really whatever the user > >> decides to work out. The idea is to be able to set/compile settings in > >> either mode at the individual package level (i.e. scholarLY, etc.), > >> and also to be able to toggle all-at-once by directing OLL's mode. And > >> individual packages will have an additional optional setting to *keep* > >> whatever mode regardless of OLL's mode, if so desired. > >> > >> The question here is about naming mostly. A `final` mode is ideally > >> the *implicit* mode, so it doesn't have to be explicitly set (though > >> it still could be). An alternative mode, `draft` would need to be > >> turned on explicitly. There have apparently been discussions in the > >> past particularly about the name "draft" (though I haven't found them > >> in my search); in any case, I'd like to know what others think about > >> that now, and of course the concept of this feature in general. > >> > >> Looking forward to your thoughts about these things, and to > >> following-up with some test-drivable results in the near future. > > > > 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")? That's probably more complex to implement, but it > > would allow switching between 3 or more modes for whatever purpose. > > Again, just a thought... > > Interesting thought - although I wouldn't want to decide this > spontaneously. But maybe some clarification about the implementation is > helpful for others to think about it. > > We're talking about openLilyLib's configuration mechanism. > ScholarLY is a package that implicitly loads openLilyLib through the > oll-core package, which in turn implements the configuration > infrastructure. > > Once oll-core is loaded there is a tree structure available holding all > sorts of options that can be handled using (among others) a \getOption > and a \setOption command. openLilyLib packages are encouraged to make > use of that mechanism to provide a consistent user interface across > openLilyLib packages. But (together with the \registerOption command) > they can also be used independently by any user file. > > Now, switching modes (like with LaTeX's class options) is handled by > setting a global option in openLilyLib. By itself this does nothing, but > packages are encouraged to respond to that setting. As an example the > ScholarLY package might apply coloring of annotated items when "draft" > mode is active and keep everything black in "final" mode. However, it is > up the package maintainer if and how the packages handles "modes". > > 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 > > > > > Thanks for your good work! > > -Paul > > > > ___ > > lilyp
Re: GSoC update; Q's about final/draft modes, and triggering footnotes
Am 29.06.2016 um 15:12 schrieb Paul: > Hi Jeffrey, > > It's good to hear about your progress! Just a thought about modes... > > On 06/27/2016 07:50 PM, Jeffery Shivers wrote: >> ***Final/"draft" Modes*** >> OpenLilyLib will ideally be used in final/draft/etc. modes in order to >> toggle between fancy/plain settings, or really whatever the user >> decides to work out. The idea is to be able to set/compile settings in >> either mode at the individual package level (i.e. scholarLY, etc.), >> and also to be able to toggle all-at-once by directing OLL's mode. And >> individual packages will have an additional optional setting to *keep* >> whatever mode regardless of OLL's mode, if so desired. >> >> The question here is about naming mostly. A `final` mode is ideally >> the *implicit* mode, so it doesn't have to be explicitly set (though >> it still could be). An alternative mode, `draft` would need to be >> turned on explicitly. There have apparently been discussions in the >> past particularly about the name "draft" (though I haven't found them >> in my search); in any case, I'd like to know what others think about >> that now, and of course the concept of this feature in general. >> >> Looking forward to your thoughts about these things, and to >> following-up with some test-drivable results in the near future. > > 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")? That's probably more complex to implement, but it > would allow switching between 3 or more modes for whatever purpose. > Again, just a thought... Interesting thought - although I wouldn't want to decide this spontaneously. But maybe some clarification about the implementation is helpful for others to think about it. We're talking about openLilyLib's configuration mechanism. ScholarLY is a package that implicitly loads openLilyLib through the oll-core package, which in turn implements the configuration infrastructure. Once oll-core is loaded there is a tree structure available holding all sorts of options that can be handled using (among others) a \getOption and a \setOption command. openLilyLib packages are encouraged to make use of that mechanism to provide a consistent user interface across openLilyLib packages. But (together with the \registerOption command) they can also be used independently by any user file. Now, switching modes (like with LaTeX's class options) is handled by setting a global option in openLilyLib. By itself this does nothing, but packages are encouraged to respond to that setting. As an example the ScholarLY package might apply coloring of annotated items when "draft" mode is active and keep everything black in "final" mode. However, it is up the package maintainer if and how the packages handles "modes". 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 > > Thanks for your good work! > -Paul > > ___ > lilypond-user mailing list > lilypond-user@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GSoC update; Q's about final/draft modes, and triggering footnotes
Hi Jeffrey, It's good to hear about your progress! Just a thought about modes... On 06/27/2016 07:50 PM, Jeffery Shivers wrote: ***Final/"draft" Modes*** OpenLilyLib will ideally be used in final/draft/etc. modes in order to toggle between fancy/plain settings, or really whatever the user decides to work out. The idea is to be able to set/compile settings in either mode at the individual package level (i.e. scholarLY, etc.), and also to be able to toggle all-at-once by directing OLL's mode. And individual packages will have an additional optional setting to *keep* whatever mode regardless of OLL's mode, if so desired. The question here is about naming mostly. A `final` mode is ideally the *implicit* mode, so it doesn't have to be explicitly set (though it still could be). An alternative mode, `draft` would need to be turned on explicitly. There have apparently been discussions in the past particularly about the name "draft" (though I haven't found them in my search); in any case, I'd like to know what others think about that now, and of course the concept of this feature in general. Looking forward to your thoughts about these things, and to following-up with some test-drivable results in the near future. 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")? That's probably more complex to implement, but it would allow switching between 3 or more modes for whatever purpose. Again, just a thought... Thanks for your good work! -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GSoC update; Q's about final/draft modes, and triggering footnotes
On Mon, 2016-06-27 at 19:50 -0400, Jeffery Shivers wrote: > Hi fellow LP users, > > Firstly, thanks to Urs for all his guidance in the project so far. The > LaTeX package for scholarLY is inching forward still, and hopefully I > will share an initial version after a few more kinks have been worked > out with a couple of the features. I'll have more substantial details > soon, and ideally all will be wrapped in some sort of early > documentation along with the package and example docs. Jeffery, thanks for your work on scholarLY. Please don't be discouraged by sparse feedback from the list: there are certainly some of us who are keen to use scholarLY but who do not know LaTeX, or are unwilling to wrap our existing lilypond scores in it. Both lilypond and LaTeX have steep learning curves, and not everyone is willing to tackle both of them. Speaking for myself, I have used \criticalRemark, but until it can produce lilypond/score footnotes it is little more than an elaborate comment in the source code. Once it can produce such footnotes, we'll be able to use it to greater effect, your user base will grow, we'll be in a position to understand some of the choices you are offering, and you'll get better feedback. Looking forward to v1.0. -- Graham ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user