lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: promoting LilyPond


From: David Kastrup
Subject: Re: promoting LilyPond
Date: Thu, 05 Dec 2013 18:48:45 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Janek Warchoł <address@hidden> writes:

> 2013/12/2 David Kastrup <address@hidden>:
>> At any rate, we need to pitch LilyPond to _ourselves_ and listen what
>> annoys us.  Particularly when explaining LilyPond to others and/or
>> pitching it to them.
>
> I can do this at any moment.  But how to make sure that it won't end
> up as another long rant that everybody reads but noone acts upon?

Oh, it _will_ end up as another long rant that everybody reads but noone
acts upon for a long time.

Issue 3682 tooks decidedly more than a year before I "acted upon" it.
That's because it's not really convincing me without issue 3648.  And
for issue 3648, things had to be sorted out in the parser before it
became feasible.  And, of course, 2.18 had to be branched off.

A lot of things take a basic constellation of things to be right before
they can be done sensibly.  But such a constellation will not be reached
by chance: one has to work on it.  And that means that one has to have
some goals in the back of one's mind.

A few months ago, I worked on the meaning and implementation of
\defaultchild and the relation to implicit contexts.  Work which seems
utterly without purpose.  It isn't.  I have some tasks in the back of my
mind which move closer to be doable because of those changes.

> For starters, we could take
> https://github.com/openlilylib/snippets/tree/master/templates/predefined-instruments
> and expand it, and add such predefined "instruments" to official
> LilyPond.  I think it would make "structural" work much easier (esp.
> for beginners).

We need to figure out how we can provide "style sheets", similar to how
LaTeX makes it possible to define "document classes" (layout definitions
and tools) and "packages" (raw functionality packaged into coherent
interfaces).

Moving in the direction where this is possible also takes some pressure
of stable/unstable development and features/fixes: something which comes
in its own, optionally used file is not disruptive to the core
stability.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]