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 and have a (non-optional ?) documentation string to be used as mouse-over? I think a unified approach to documentation might go a long way towards basic usability. -- David Kastrup