Alexander Kobel <n...@a-kobel.de> writes: > David Kastrup wrote: >> Alexander Kobel <n...@a-kobel.de> writes: >>>> 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. [...] 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"? > > Hum. To my understanding, the point why Eluze and you recommend not to > use \parallelMusic is the lack of a standard for it - which, IMHO, > misses the opportunity to ease your work, regardless of the current > state of implementation and/or defintion of the command.
I am not talking about whether to use or not \parallelMusic, but whether it belongs in the core rather than the LSR in its current state. And whether one should consider it a bug that it breaks under several circumstances. "I am not surprised that it breaks" does not really address that. > I'll make a better use of my time, and try to put together an example > of why I'm still in favor of it. Mostly I am in favor of making it work. As consistently as not suddenly become useless for certain standard situations, and such that Lilypond file readers other than Lilypond (for example, convert-ly) have a chance to get it right. And while its behavior with regard to repeats and relative notes is not what a user would expect, I am not in favor of declaring the existing state "standard". -- David Kastrup _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
