Re: can a Scheme engraver "solve" Issue #34 (grace note bug)? [cross-posted]

[Lukas-Fabian Moser]

Am 08.02.20 um 21:44 schrieb Han-Wen Nienhuys:
> I think the right solution would be to kill grace timing altogether, and
> initiate some sort special "embedded" engraving pass that creates the Grace
> grobs all at once.
>
> That would have another downside: if we construct the grace note grobs in a
> special pass, there is nothing to synchronize them across staves. You could
> have two-handed piano music where the left and right hand do grace notes in
> a synchronized way. I don't if that exists in practice, but it is one of
> the reasons for the current approach.

I would expect that synchronized grace notes do exist. But more often 
than not, at least one solitary grace note is meant to happen "some 
infinitesimal amount of time before the main note", without a need to 
keep track of (so-to-say) different lengths of infinitesimal moments 
across voices/staves.

Hence, in combination with accidentals, the current approach leads to 
ugly things like

\version "2.19.82"

<<
  \new Staff { \grace a'8 gis'2 }
  \new Staff { \grace dis'8 e'2 }
>>

(which I encountered quite a lot when engraving, for instance, examples 
from Mozart chamber music).

My standard workaround is to allow LilyPond to use two different points 
in grace time:

\version "2.19.82"

<<
  \new Staff { \grace a'8 gis'2 }
  \new Staff { \grace dis'8*1/2 e'2 }
>>

But that's also not ideal, firstly from a semantic point of view, 
secondly because the visual outcome depends on the chosen factor, while 
I basically want Lily to put the grace not "as close as 
possible/graphically sensible" to the main note.

Best
Lukas