Re: markup-command and markup-command-list signatures

[David Kastrup]

"Boris Shingarov" <address@hidden> writes:

> On Mon, 03 May 2010 09:02:55  0200, David Kastrup  wrote:
> "Boris Shingarov" <address@hidden> writes:
>> > Markup functions being able to return a list of stencils. 
>  >
>  > Markup lists don't do the trick here?
>  
> No; if you look at patch 207105, you'll see what I mean.  
>> I don't see that you stand a chance with the standard processes
>> here. 
> [...]
>  > Basically you'll be on your own going against the tide until you are
>  > finished.  The work flows here are designed to achieve code quality by
>  > making it harder for a would-be contributor to get sub-par code through,
>  > not by making others participate with the work. 
>
> I guess even that assessment is overly optimistic.
> The real problem here is not of process, but of fundamental
> interests.  I am scratching *my* itch, which is, make
> top-publication-grade work possible with Lilypond.

If you take a look at Lilypond documentation at the web page, you'll see
that this focus is supposed to be a major goal of Lilypond.  So that
should not be an impediment.

> Lilypond did not reach this grade before.  So this work is beneficial
> to the Lilypond community in two ways: proving we can go on that
> territory, as well as purely technical contributions.  Now, with
> technical contributions that are easy enough to integrate back
> upstream, ok I can spend the extra 30% effort to integrate; but 500%
> does not seem justifiable

The main problem I see with Lilypond is that its development processes
are falling apart due to the high complexity it has gained through the
mixture of flex/bison/C++/Scheme/PostScript and the consequence that
very few people are knowledgable with all of its parts and
interoperations (in particular the details of tying together contexts,
translators and interfaces, hidden deep in the bowels of C++).  And
those that are, are busy.  Catering for your requirements without
bogging separate material on in inconsistent and intractable ways is
going to take deep surgery.  The resulting code needs to be tied in as
well as if it was originally designed in that manner, or nobody will be
able to learn dealing with it in sensible amounts of time.

You see the current state of page breaking: the appearance is that not
more than one person, possibly less, understands it fully at the current
point of time.  Or at least can be bothered about looking at it.

> But I am open to any suggestion how to make it more useful to the
> community.

The code alone will not be useful would be my guess.  It sounds like it
might be viewed like a proverbial Trojan horse where tearing down the
walls to let it in will weaken the project's defenses against
unmaintainability.  My personal advice to you is to consider it and
treat and value it like a proof of concept: it shows that something
_can_ be done to address your problem space.  Even by a single person
that is not a core developer.  A proof of concept is a whole lot better
than nothing in your hands.  Presenting its design and results achieved
with it will be a good step forward to make others move with you.
Trying to make the proof of concept code changes as self-contained as
possible so that people have less work understanding what you are doing
will also help for getting others interested and to understand, even
though the end product is desired to be well-integrated into the overall
design.

That's my take on it, but of course you are aware of my standing here.

-- 
David Kastrup