On Sat, Oct 13, 2012 at 5:07 PM, David Kastrup <d...@gnu.org> wrote: > Janek Warchoł <janek.lilyp...@gmail.com> writes: >> would it hurt us really much to have multiple overrides >> "accumulate cruft"? I suppose that in real-life situation there won't >> be that much cruft accumulated - but i might be completely wrong. > > \voiceTwo \voiceOne \oneVoice > > Would you expect that after this sequence, the state is like just after > \voiceTwo?
Good point. >> In other words, we have \override, \tweak, \set, \revert, \unset, >> \undo, \single (and maybe more). It's getting confusing, at least for >> me. I'd prefer to decrease the number of such functions, not increase >> them (without deleting functionality, of course). > > You can't call functionality without an interface. A prefix like > \temporary is better than a full new interface. > > It's really totally unrewarding to do this kind of work. Instead of > "Great, finally we get a tool for doing x in a straightforward way", > everybody is always hollering "oh no, not another tool. Can't we just > live with the deficient state?" > > Have you ever tried working with a combined hammer, tongs, screwdriver, > drill multi-tool? If you have, you'd value a clean, sorted toolbox with > simple and separate tools that all do just one job, and do it well. > > Again: if you don't _care_ about breaking things, then _don't_ learn how > to avoid it, and you will be just fine. > > Me, I am annoyed at broken things. So I want to have the tools > available that help me deal with that. But people are free to ignore > that offer. David, from your reaction i deduce that you felt attacked by me. I'm sorry as this wasn't my intent. I want to have this situation explained as soon as possible. Please, choose any voip software you like (i understand that you don't want a gmail account nor skype account because of their privacy policy) which can run on Ubuntu, and let's have a voice chat, ok? I can be online tomorrow 9-22 your time. worried Janek _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel