Menu
▾
▴
#2536 Patch: Make \footnote work via \tweak
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
So far, I only changed two regression tests (they are complex enough to not bow to automatic conversion).
footnote-auto-numbering-page-reset.ly
footnote-auto-numbering-vertical-order.ly
They can serve as an example how the use of \footnote has now become simpler. The patch, unfortunately, is rather large due to the necessity of reverting the already commit footnote change to postevent syntax: that was a step in the opposite direction of _this_ change.
Labels: -Patch-new Patch-needs_work
Owner: dak@gnu.org
Status: Started
Originally posted by: dak@gnu.org
Ok, here is the first problem: changing TimeSignature. This grob is an indirect consequence of a change in Timing properties, consequently its cause is #'().
It would seem like a natural fit to forget about the ultimate_event_cause stuff in \tweak. Instead, when grob types are specified, \footnote works as previously, possibly using a FootnoteEvent. However, this glosses over the fact that \footnote _does_ receive a music argument which would then disappear. It would need to be something that can disappear without problems, perhaps even #'() or \default.
Another possibility would be to introduce a way in which \tweaks can travel to indirectly created grobs, like that of \time or \clef. That would be ultimately more elegant and understandable. However, it would be piecemeal work. If the first option is implemented, one can do the second option by and by.
Why does life need to be so complicated?
Originally posted 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.
http://codereview.appspot.com/6195098
Labels: -Patch-needs_work Patch-new
Originally posted by: dak@gnu.org
I recovered the old behavior by adding \default at the end of the \footnote expression. This will yield a path for automatically working convert-ly rules (but I need to go to bed right now). For performance reasons, the c-\footnote ... \default form should eventually be retired since \footnote ... c works just as well.
Expect a working convert-ly conversion tomorrow, and the followup work from then on should be able to clear Patchy in docs and regtests again, even though manual cleanup work is definitely called for.
Labels: -Patch-new Patch-needs_work
Originally posted 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.
http://codereview.appspot.com/6195098
Labels: -Patch-needs_work Patch-new
Originally posted by: dak@gnu.org
Patchy the autobot says: passes tests.
Labels: -Patch-new Patch-review
Originally posted 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.
http://codereview.appspot.com/6195098
Labels: -Patch-review Patch-new
Originally posted by: dak@gnu.org
Patchy the autobot says: passes tests.
Labels: -Patch-new Patch-review
Originally posted by: dak@gnu.org
Working on the docs and regtests (the result of the automatic conversions is using the old, complex way of applying footnotes).
Example screenshot of the ongoing work attached; please take a look. I like the current tradeoff between power and complexity. You almost never need to specify a grob type, and attaching footnotes to articulations is straightforward. It is a bit of a nuisance that one has to remember writing -\footnote for postevents. I think I should try to remove the distinction between music functions and event functions eventually: the resulting music expression type should suffice for determining the post-event character. But that is a different change.
Originally posted 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.
http://codereview.appspot.com/6195098
Labels: -Patch-review Patch-new
Originally posted by: dak@gnu.org
Marking as critical since it is blocking 2505 (hopefully obsoleting it if people can agree).
Labels: -Type-Enhancement Type-Critical
Originally posted by: dak@gnu.org
Patchy the autobot says: A bunch of programming errors after manual changes using the tweak interface. Fix is obvious.
Labels: -Patch-new Patch-needs_work
Originally posted 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.
http://codereview.appspot.com/6195098
Labels: -Patch-needs_work Patch-new
Originally posted 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.
http://codereview.appspot.com/6195098
Originally posted by: dak@gnu.org
Patchy the autobot says: still an undead protected object. Need to hunt this down. Functionally, everything looks ok.
Labels: -Patch-new Patch-needs_work
Originally posted 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.
http://codereview.appspot.com/6195098
Labels: -Patch-needs_work Patch-new
Originally posted by: dak@gnu.org
Patchy the autobot says: passes tests.
Labels: -Patch-new Patch-review
Originally posted by: ColinPKC...@gmail.com
(No comment was entered for this change.)
Labels: -Patch-review Patch-countdown
Originally posted 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.
http://codereview.appspot.com/6195098
Labels: -Patch-countdown Patch-new
Originally posted by: dak@gnu.org
(No comment was entered for this change.)
Blockedon: 2540
Originally posted by: dak@gnu.org
Patchy the autobot says: passes tests. This does change a number of profiles, apparently due to a different order of regtest execution after changing them and their hashes, and the graphviz test. Nothing noteworthy otherwise.
Labels: -Patch-new Patch-review
Originally posted by: dak@gnu.org
Put back to countdown since the changes were marginal (actually forming issue 2540) and tested well.
Labels: -Patch-review Patch-countdown
Related
Issues:
#2540Originally posted by: ColinPKC...@gmail.com
Counted down to 20120520, please push
Labels: -Patch-countdown Patch-push
Originally posted by: dak@gnu.org
Pushed as
commit [rc20bed72fb602fabf67087649df283f1978a9d94]
Author: David Kastrup <dak@gnu.org>
Date: Thu May 17 16:08:33 2012 +0200
Manual changes to documentation and regtests for footnotes.
commit [rf2bd555640f6f28276fd56250c7e8b1bd07aa1df]
Author: David Kastrup <dak@gnu.org>
Date: Thu May 17 11:10:16 2012 +0200
Run scripts/auxiliar/update-with-convert-ly
commit [r3f20c6178c3090afdf495f66b595677388a21629]
Author: David Kastrup <dak@gnu.org>
Date: Wed May 16 16:47:41 2012 +0200
Make \footnote work via \tweak
commit [r4a81b4d1f1706e503b0bb8fd7c80be3c825cc96c]
Author: David Kastrup <dak@gnu.org>
Date: Tue May 15 11:55:28 2012 +0200
Revert "Merge branch 'footnote' into HEAD"
This reverts commit [r2ec0cd55d55c49dee4e5604903dfab8ff4a089c4], reversing
changes made to [r0a0274a3bf5792dfb7ce3719f5dfaef36059affe].
commit [rd06ebc90ec926e435ec00f5fb18dec838928df20]
Author: David Kastrup <dak@gnu.org>
Date: Wed May 16 20:32:00 2012 +0200
parser.yy: split function_arglist_nonbackup rule into closed and open varian
This allows more cases where optional arguments are not really optional
to accept music arguments not enclosed in braces.
to staging, after the pushes for issue 2540 and issue 2539.
Blockedon: -lilypond:2540
Labels: -Patch-push Fixed_2_15_39
Status: Fixed
Related
Issues:
#2540Originally posted by: Elu...@gmail.com
(No comment was entered for this change.)
Status: Verified