Am Dienstag, den 21.01.2020, 11:19 +0100 schrieb Urs Liska: > > Ok. One thing to think about is that we want package files to be > > contributed by "ordinary" users. But something like > > > > \exportSymbols transposeSequence,instrumentGroup,scratchMyBack > > > > would be perfectly feasible syntactical sugar. > > > > I'll be more verbose than probably necessary, just to make sure we're > talking about the same thing. > > ... > > If I got you right then from my experience with openLilyLib and > creating project environments (which basically are the same as > packages), I would say: > > * I'm all for hiding names in packages by default and having to > explicitly expose/export the package's interface >
One more implication: If variables and functions have to be explicitly exported it will be easier for external tools (like Frescobaldi) to add proper support for extensions. I assume that at one point Frescobaldi will * know about available (core and external) extensions * provide ways to "use" an extension (as part of the Score wizard and locally) * at that point know about the options that can be passed to that package * provide autocompletion and highlighting for available symbols exported from extensions * provide actions to generate the code for getting and setting package options So when planning the syntax of that export it would be good to take the needs/interest of IDEs into account that will not work with the result as LilyPond does but that parse the package files themselves. Urs