Thanks for looking into it.
The issue describes the situation well. I've almost succeded in
implementing the first solution with config (in oll core), but it was too
messy so I dropped it. But then, the new proposal with "applyOpts" seems
to be more elegant.
Will keep an eye on oll activity,
Pedr
Hi Pedro,
I've now looked into the code, and the issue is the following
\loadPackage \with {
option = "B"
} local
will set the option correctly, but only *after* loading the package.
This means the option is available within your test.ly file after
loading the package. This is
Hi Pedro,
Am 31.03.19 um 04:30 schrieb Pedro Pessoa:
The ideia for the "local" package is to make a clear distinctions
between remote and local files. Like so:
[ root ]
|- - oll-core
|- - edition-engraver
|- - lalily-templates
|- - ... etc
|- - [ local ]
|- - common (shared functions for l
The ideia for the "local" package is to make a clear distinctions between
remote and local files. Like so:
[ root ]
|- - oll-core
|- - edition-engraver
|- - lalily-templates
|- - ... etc
|- - [ local ]
|- - common (shared functions for local packages)
|- - lalily-templates (user extended f
Hi Pedro,
Am 30. März 2019 23:45:07 MEZ schrieb Pedro Pessoa :
>Hello,
>I'm trying to use OLL infrastructure to organize my local toolset. I'm
>mostly trying to mimic the structure of other packages and modules.
>I've an
>aparently working package called 'local', where I intend to put all my
>pers
Hello,
I'm trying to use OLL infrastructure to organize my local toolset. I'm
mostly trying to mimic the structure of other packages and modules. I've an
aparently working package called 'local', where I intend to put all my
personal tools as modules/submodules.
I'm currently having an apparently
