Am Mittwoch, den 22.01.2020, 11:43 +0100 schrieb Urs Liska: > Am Mittwoch, den 22.01.2020, 11:06 +0100 schrieb David Kastrup: > > Urs Liska <li...@openlilylib.org> writes: > > > > > 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. > > > > Maybe we should have single-command exports after all > > You mean that a package has to export every function or variable > separately? I think that would be good wrt self-documentation. >
This gave me another idea: How would it be if elements (functions, variables, whatever) exported by packages would have to be addressed through a package namespace: * scholarly.annotate exports \criticalRemark * this can't be used with \criticalRemark but (syntax of course up to the parser maintainer ;-) ) \scholarly.annotate.criticalRemark That way the global namespace would be less pollutable, and identical names in different packages wouldn't be an issue. A user can still do something like criticalRemark = scholarly.annotate.criticalRemark as a local shorthand. Urs
