Re: Packages/modules

[David Kastrup]

Urs Liska <address@hidden> 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