Re: Quick question about accidentals

[David Sumbler]

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 <address@hidden> 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.
>