Kieren MacMillan <[email protected]> writes: >> So what? That's more of a reason to get rid of the idiosyncrasies >> rather than providing incomplete commands with strange semantics >> that people then start relying on. > > Which is exactly why I posted my question in the first place: trying > to promote the elimination of [one of] Lilypond's idiosyncracies. > > In any case, there are too many idiosyncracies for the small > development team to take care of "immediately". Hence we are forced to > use (and "start relying on") many, many, many, many — is my point > clear yet? — many, many "incomplete commands with strange semantics" > in order to get our work done. > > At least some of us use Lilypond very heavily on a daily basis. For > example, this week alone I: finished composing and engraving a > 12-minute song cycle for piano, cello, and voice; updated scores of > three different (all relatively complex) multi-act music dramas; and > prepared score files for five movements which will include very large > forces (double orchestra plus three smaller ensembles plus two choirs) > to be filled in with new compositions/arrangements over the next few > weeks. > > Waiting around for proper implementations of things like temporary > polyphony is not a real option if I want to get my work done in a > timely fashion.
Sure. But the simple workarounds are easy to do _and_ understand. If you feel that the respective approaches are underdocumented, you may be right. But the solution for not understanding how something works is documentation, not wrapping something into a function for which one does not understand how it will work in practice. Music functions provided by LilyPond are documented blackboxes. They should do a given job well, and reasonably completely and comprehensively. They should solve a _task_, rather than being a shortcut for a somewhat useful piece of code related to a task. What you propose as "\split" is too hackish and limited and arbitrary to turn into a core music function. That does not mean that something like that should possibly be explained more thoroughly in the documentation. But it does not reach the level of a turnkey solution. -- David Kastrup _______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
