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

[Jeffery Shivers]

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

[Simon Albrecht]

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

[Jeffery Shivers]

​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

[Jeffery Shivers]

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

[Urs Liska]

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

[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.


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

[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 
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

[Jeffery Shivers]

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

[Paul]

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

[Jeffery Shivers]

>
> 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
> >
> > 

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

[Urs Liska]

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

[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...


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

[Graham King]

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

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

[Jeffery Shivers]

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.

I would like to ask for some feedback regarding two general topics.

***Footnotes***
Currently, in the annotation interface, we can set an `ann-footnote`
property which is sent to LaTeX as a footnote for the entire
annotation message (and not realized in LilyPond as an in-score
footnote). That is particularly useful/necessary for making sure that,
if used, the superscript would be placed *after* punctuation and
quotes (or whatever else might be used). Additionally any `\fn...`
used in a message property, such as `\fnSpecialNote` will link to the
value associated with `fn-special-note-text` if set (which is also
only applied in LaTeX and *not* lilypond, i.e. the score itself). So,
in use:

\criticalRemark \with {
message = "My message with\fnUnique two footnotes."
fn-unique-text = "A footnote within the message."
ann-footnote = "A footnote for the entire message."
} NoteHead c4

My question, since another aim is to actually trigger lilypond/score
footnotes from within annotations as well, is *how* you would
want/expect that to be implemented, including the nomenclature. My
initial thought is to add `score-footnote` as an additional (optional)
property in the annotation interface, and automatically link it to the
corresponding grob. It seems straightforward enough, but I want to be
sure I am not overlooking some other way of approaching this that
would be more intuitive.

***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.

all best,
Jeffery

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user