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 <address@hidden> 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
>
> _______________________________________________
> lilypond-user mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-user


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