lilypond-user
[Top][All Lists]
Advanced

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

Re: parallelMusic and repeat


From: David Kastrup
Subject: Re: parallelMusic and repeat
Date: Tue, 08 Dec 2009 23:12:13 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux)

Alexander Kobel <address@hidden> writes:

> David Kastrup wrote:
>> Alexander Kobel <address@hidden> writes:
>>>> -Eluze <address@hidden> writes:
>>>>> i think \parallelMusic is just thought for a quick and easy input -
>>>>> without sophisticated structuring of a piece!
>>> Although it's an example of a functionality that IMHO is to valuable
>>> to be hidden inside the LSR without mentioning it in the NR,
>>
>> If it is valuable, doing it properly should be a priority.  The current
>> workflow does not seem to make the requisite bug reports/tasks appear in
>> parallel with the first draft implementation of a feature.
>
> I also can't remember an enhancement request asking for, say,
> \vspace. It was written by someone (Nicolas?) who needed it, someone
> found it, thought: Hey, that's cool, and well, now it's there, without
> standardization. I'd not be surprised if you can find errors there, or
> "unspecified behaviour" - e.g., what's the width of this "invisible
> object"? - but that does not impair its right to exist.

We are not talking about "right to exist", but standard, part of core,
being supported in eternity by convert-ly and whatever else that
implies.

>>> and having it in the core at least gives a /little bit/ of
>>> standardization.
>>
>> Standardization does not mean "let's call the current inconsistent
>> ad-hoc behavior standard".  A standard needs to make sense of its
>> own, not just be a side-effect of a particular implementation.
>
> Ah, come on. Of course your reasoning is correct, I know. I do believe
> in standards, as well, and as often as I can I try to use and
> propagate them.
> But there's a whole bunch of great standards, which deeply lack one
> thing: proper implementation and support (remember CSS and
> XHTML?). And there's a bunch of great features, as well, which don't
> follow a well-defined standard, but are incredibly valuable from a
> practical point of view.

So where is your point?  Remember: the issue was _standardization_, as
quoted from your posting above.

> It's one thing to try to refine the latter, but as long as they get me
> my work done, I surely won't reject them for purely ideological
> reasons, and rather stick to defaults than standards.

So why are _you_ then talking about "standardization"?

> And it's being in the core means I have more-or-less well defined
> behaviour, which I can rely on even when reading code from others or
> myself, later on.

No, well-defined means first of all _defined_.  And _defined_ needs a
_definition_.  Code that is not an implementation of a definition is not
the same.  Because then _by_ _definition_ the code is not buggy and
can't be improved, because it _is_ the definition.

> I'm not saying it's not worth it, but it's quite an involved task.
> And I really don't get why we demonize the current state. I mean,
> although it's a hack: What actually /is/ bad about \parallelMusic?

That it breaks in incoherent ways and circumstances that you could not
guess from looking at its manual page, or from any inherent features
from the "definition".

-- 
David Kastrup





reply via email to

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