Originally created by: *anonymous
Originally created by: dak@gnu.org
Originally owned by: dak@gnu.org
Make \footnote work via \tweak
Allow Tweak_engraver to take a (grob.property) pair as tweak address
Revert "Merge branch 'footnote' into HEAD"
This reverts commit [r2ec0cd55d55c49dee4e5604903dfab8ff4a089c4], reversing
changes made to [r0a0274a3bf5792dfb7ce3719f5dfaef36059affe].
Those are the three commits currently making up this issue. The music
function \footnote, in addition to the arguments it already takes, now
takes an additional music argument, either a chord constituent, or a
music event on its own, or a postevent (in which case, like \tweak,
you should invoke \footnote with an explicit event character - in
front of it). The footnote is visible on any Grob directly caused by
the following event in the source code (the additional music
argument), unless a grob-name is specified, in which case it will
appear on any grob of that type _ultimately_ caused by the following
event (a Flag is directly caused by a NoteHead grob, but ultimately by
a NoteEvent).
I had been considering placing the anchoring Music event as first
argument of \footnote. However, that makes for totally awful nesting
syntax in case you attach several footnotes to the same Music.
Originally posted by: dak@gnu.org
As a postscriptum: the syntax currently is more or less:
\footnote ["mark"] offset [#'Grob] "footnote text" [music]
With a non-greedy approach to argument matching regarding multiple arguments of the same kind, one could make this
\footnote [Grob] offset ["mark"] "footnote text" [music]
a much, much more natural syntax. With the greedy approach, an optional argument before an argument of the same type does not make sense. While it would appear that one can effectively do this as
\footnote [Grob] offset "mark-or-text" ["text-when-mark"] [music]
instead, optional arguments at the end of an argument list are not really optional unless you explicitly write \default, and a single \default exhausts any _consecutive_ optional arguments, so there would be no way to _not_ have a mark, but still have music.
So this is definitely an improvement that would be worthwhile to make once the parser is in a state making it feasible.