Menu
▾
▴
#2505 Patch: Doc: NR clarified \footnote command as a TextScript
Invalid
nobody
None
needs_work
Critical
2012-05-19
2012-04-28
Anonymous
No
Originally created by: *anonymous
Originally created by: pkx1...@gmail.com
Doc: NR clarified \footnote command as a TextScript
While chorded notes *require* the \footnote command attached
as a TextScript, normal notes can _also_ be attached like that.
The original description stated the command *must* come before
single notes.
Originally posted by: pkx1...@gmail.com
(No comment was entered for this change.)
Labels: -Type-Enhancement Type-Documentation
Owner: pkx1...@gmail.com
Status: Started
Originally posted by: ColinPKC...@gmail.com
Patchy the autobot says: LGTM.
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: ColinPKC...@gmail.com
Comment from Graham on Rietveld.
Labels: -Patch-countdown Patch-needs_work
Originally posted by: pkx1...@gmail.com
http://codereview.appspot.com/6137050/diff/1/Documentation/notation/input.ite...
Documentation/notation/input.itely:1050: footnote is being attached but can also
be attached as a
On 2012/04/30 07:39:21, Graham Percival wrote:
> isn't a textscript also a grob? if so, you don't need to add that in the
text.
> The example carries that story.
Possibly, I don't actually know the technical difference, I was following the
examples I did previously (if you scan down to the start of the 'manual'
footnotes and the 'chorded' notes I've just tried tied to be consistent and that
is what I used there. That was based on comments by Mike (and possibly David
when he made his changes), so if TextScript and Grob are interchangeable I
should make the changes throughout the @nodes than just here.
If someone can let me know?
Originally posted by: pkx1...@gmail.com
Doc: NR clarified \footnote command as a TextScript
While chorded notes *require* the \footnote command attached
as a TextScript, normal notes can _also_ be attached like that.
The original description stated the command *must* come before
single notes.
http://codereview.appspot.com/6137050
Labels: -Patch-needs_work Patch-new
Originally posted by: ColinPKC...@gmail.com
Patchy the autobot says: LGTM.
Labels: -Patch-new Patch-review
Originally posted by: pkx1...@gmail.com
(No comment was entered for this change.)
Labels: -Patch-review Patch-needs_work
Originally posted by: dak@gnu.org
The documentation changes should be done in the wake of cleaning up the convert-ly actions of issue 2518. Those result in <>\footnote ... before notes and chords and should be converted into \footnote following them. Which is basically the same kind of action that the documentation should propose: footnotes following their anchors.
Blockedon: 2518
Originally posted by: dak@gnu.org
Can we coordinate the now required work on this issue with issue 2518? It would be preferable to check them in as one sequence to avoid
a) extended appearance of <>\footnote in the docs and snippets: that's only generated because moving the \footnote across the following event is too complex for a convert-ly rule, and that way we at least have an automatic rule with working result
b) divergence of text and code
The basic question is who should do the <>\footnote cleanup since it will clearly be happening in conflicting regions with the documentation changes.
Originally posted by: pkx1...@gmail.com
If by 'co-ordinate' you mean that if we leave doc until 'later' that the changed code will break make doc, I suggest you attach a git formatted patch of the fixed code, I can apply it my local repo and redo the examples for \footnote (and make any other text changes), that way I can also test the examples still work with my own local make. Then I can revert your patch, create mine and then they can be checked separately and applied separately but at the same time (or you can have my final patch yourself).
Does that sound right?
Originally posted by: dak@gnu.org
The changed code will not break "make doc": convert-ly takes care of that. It will, however, look decidedly stupid if the text says something like "footnotes come after the notes to which they are attached" and the code looks like
<>\footnote "text"
c
instead of
c\footnote "text"
The output will be the same, but autocorrecting the input to move the footnote across whatever simple event may follow is too complex to do for convert-ly. Attaching it to <> means that the autoconversion can leave it in place. But for something that people will actually _look_ at, we should manually correct the source. This is not supposed to smuggle in <> through the backdoor: it is actually the only thing that will work here for an automatic conversion (which made me come up with the idea in the first place). But that does not mean that the conversion result is fit for human consumption.
Originally posted by: dak@gnu.org
Ok, here is how we do this: it does not make sense to keep the footnote syntax backwards in the first stable release. So I am pushing the syntax change. I am also marking this issue as Critical: it does not make sense to release "stable" without the doc being fixed, and having the footnote change already pushed should make it easier for you to adapt the documentation:
git grep '<>' Documentation
should more or less turn out blank.
Blockedon: -2518
Labels: -Type-Documentation Type-Critical
Originally posted by: pkx1...@gmail.com
OK I am aware of this, it is not forgotten. I will get to this tomorrow afternoon (12th) and put up a patch.
Originally posted by: pkx1...@gmail.com
Doc: NR clarified \footnote command as a TextScript
While chorded notes *require* the \footnote command attached
as a TextScript, normal notes can _also_ be attached like that.
The original description stated the command *must* come before
single notes.
http://codereview.appspot.com/6137050
Labels: -Patch-needs_work Patch-new
Originally posted by: pkx1...@gmail.com
Doc: NR clarified \footnote command as a TextScript
While chorded notes *require* the \footnote command attached
as a TextScript, normal notes can _also_ be attached like that.
The original description stated the command *must* come before
single notes.
http://codereview.appspot.com/6137050
Originally posted by: ColinPKC...@gmail.com
Patchy the autobot says: LGTM.
Labels: -Patch-new Patch-review
Originally posted by: pkx1...@gmail.com
Doc: NR clarified \footnote command as a TextScript
While chorded notes *require* the \footnote command attached
as a TextScript, normal notes can _also_ be attached like that.
The original description stated the command *must* come before
single notes.
http://codereview.appspot.com/6137050
Labels: -Patch-review Patch-new
Originally posted by: ColinPKC...@gmail.com
Patchy the autobot says: LGTM. Still looks good to me.
Labels: -Patch-new Patch-review
Originally posted by: pkx1...@gmail.com
Doc: NR clarified \footnote command as a TextScript
While chorded notes *require* the \footnote command attached
as a TextScript, normal notes can _also_ be attached like that.
The original description stated the command *must* come before
single notes.
http://codereview.appspot.com/6137050
Originally posted by: ColinPKC...@gmail.com
(No comment was entered for this change.)
Labels: -Patch-review Patch-countdown
Originally posted by: pkx1...@gmail.com
Doc: NR clarified \footnote command as a TextScript
While chorded notes *require* the \footnote command attached
as a TextScript, normal notes can _also_ be attached like that.
The original description stated the command *must* come before
single notes.
http://codereview.appspot.com/6137050
Labels: -Patch-countdown Patch-new
Originally posted by: pkx1...@gmail.com
Patchy the autobot says: LGTM.
Labels: -Patch-new Patch-review
Originally posted by: dak@gnu.org
Ok, I am officially an idiot. When I proposed using a postevent, I had only thought about notes and rests, but footnotes may appear in a number of other places.
And something like
\breath <>\footnote #'BreathMark ...
is decidedly ugly, and
\breath c'\footnote #'BreathMark ...
is even breathtakingly ugly.
Changing \footnote back into a normal music event does not mean that it can't, in general, not be used as a postevent, you just have to remember writing - before it.
Another possibility would be to let it actively _take_ a music argument and be a music function (like \tweak except for argument order). Then we would have
\footnote\breath #'(2 . 3) "Zis iz a brezmak"
\footnote c2 #'(1 . 2) "A c note"
<c \footnote e #'(0.4 . 3) "a third">4
c-\footnote -3 #'(3 . 2) "a fingering"
This would have the material to footnote always in a fixed position and would rarely if ever require specifying a particular grob.
While it would be possible to have the material to attach to follow at the end (like with \tweak), I think it is a bit more natural to use the above order, and it turns out that the parser is up to it nowadays.
Yes, I know, critical issue and everything. Sue me. I'll probably have to revert the merge commit for the previous footnote change in issue 2518, but that should work out reasonably well as long as _this_ patch has not been committed.
Oh, and this argument order won't work for an automatic convert-ly rule. For an automatic convert-ly, the argument to attach to would have to be last, so that would be
\footnote #'(2 . 3) "Zis iz a brezmak" \breath
\footnote #'(1 . 2) "A c note" c2
<c \footnote #'(0.4 . 3) "a third" e>4
c-\footnote #'(3 . 2) "a fingering" -3
The internals are very much the same, so I'll start working on it. But there should be agreement on the syntax. I like the first variant better, but it means we (and everybody else) have to convert \footnote use manually.
The second variant would likely _mostly_ continue to work. Hm. Perhaps that is not good enough anyway.
Cc: mts...@gmail.com
Originally posted by: pkx1...@gmail.com
Would having a new command help where we can 'encapsulate' the ugly syntax in a discrete command.
I struggle with understanding the technical difference between scripts and grobs and the like but general people understand the difference between a note (inc. its stem/bar/flag/accidental) and a non-note (breath mark, clef, bar line etc) and a piece of text (header).
That doesn't really help but it might be easier to come up with a command syntax than try to make the code work in all cases or is this just like the 'lipstick on a pig' that Keith referred to?