Thanks for these 2 replies. I have tidied things up a bit by using \once \omit Accidental
as suggested by Noeck. David's reply has given me several things to look up and think about (which is good!). The quoted "@", \single and \etc were all effectively new to me - although I must have read about them more than once in the NR. I don't think I understand them well enough even now, though, for me to have invented "@"=\single \omit Accidental \etc David S. On Sat, 2016-11-26 at 16:01 +0100, David Kastrup wrote: > Noeck <[email protected]> writes: > > > > > Hi David, > > > > yes, I think there is no such command as short as ?. > > > > > > > > Using '\once \override Accidental.stencil = ##f' isn't too > > > onerous - > > > but I just wondered if there was an even easier way. > > \once \omit Accidental > > is the same and it is a bit shorter but no way near ! or ?. > "@"=\single \omit Accidental \etc > > { @cis1 } > > > > > Of course, you can always define a command like > > no = \once \omit Accidental > yes > > > > > I don't know of an accidental style which treats line breaks > > differently. But in general, this might be possible to define. > No. Line breaks interfere with the accidentals on tied notes, and > the > treatment of those is hard-coded into the accidental glyph rather > than > the accidental style. One consequence is that > > <https://sourceforge.net/p/testlilyissues/issues/649/> > > is a long-standing issue since it concerns accidentals that are _not_ > right after a line break but still related to it. > > The accidental styles have no notion of line breaks and they are > interpreted at a time where they could not take them into account. > Basically a line break should usually invalidate all accidentals like > a > clef change does (any position that has a pending accidental > differing > from the key signature will unconditionally get an accidental whether > or > not it agrees with the key signature or the last accidental on the > previous line). And when this forces an accidental not otherwise > printed, it might also affect _subsequent_ accidentals. > _______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
