Re: improving LilyPond useability

[David Kastrup]

Yann <address@hidden> writes:

> About this, I also like the fact in LaTeX that once I find the package
> that does what I want, I can read the associated doc and use it. Most
> of the time it is as simple as "load this package, specify options"
> and use some new commands if provided. What I mean is that the
> procedure is somewhat standard and unified.
>
> However, I have a question : it has been suggested to use the package
> capability to implement new features, that could be merged later on to
> the main Lilypond release. If that happens, what is done with the
> package ? Does it stays outside Lilypond core as an external package ?
> or is it merged inside ? So do we still have to include/usepackage it
> ? (just bouncing ideas, it will surely depend on how all this
> mechanism is implemented, if this work is done).

I think it would make sense not to automatically include every
conceivable package.  That way, naming conflicts are avoided.  Also some
packages might provide conflicting functionality.

GUILE offers an autoload mechanism that might conceivably be employed.
Using this would not help with the naming conflict aspect, but it would
make it possible to just import the symbols of a package when it is
loaded from the LilyPond source or a user file, and only load the
package itself if it is actually used.

This could be handy for "house styles" or "document classes" that
guarantee the availability of a lot of packages without actually having
to load their body unless it is called for.

> I came across several projects (Lalily, openlilylib, orchestralily, or
> Nicolas Sceaux scores) that seemed to have very nice features (didn't
> explore much though, sorry). Would be great if these could somehow
> benefit of some standardised package like interface.

Of course, the goal would be to have the system flexible enough to let
the authors of these systems adapt their systems to using it without too
much of a hassle.

-- 
David Kastrup