Let \footnote do the job of \footnote, \footnoteGrob, \autoFootnote and \autoFootnoteGrob

Let \footnote do the job of \footnote, \footnoteGrob, \autoFootnote and \autoFootnoteGrob

and

Run scripts/auxiliar/update-with-convert-ly.sh

Since most of the changes are done by convert-ly, reviewable changes are confined to ly/music-functions-init.ly and python/convertrules.py.

The notation manual has not been revised yet.

[pkx166h, 2012-01-09 20:42:30]

Does this do anything to the
\auto-footnote

command as well?

[Carl, 2012-01-09 20:49:21]

Looks *very* good to me!

I really like having only one \footnote command; it's intuitive for users. 
Thanks for doing this!

[pkx166h, 2012-01-09 20:51:27]

On 9 January 2012 20:49,  <Carl.D.Sorensen@gmail.com> wrote:
> Looks *very* good to me!
>
> I really like having only one \footnote command; it's intuitive for
> users.  Thanks for doing this!

On the shoulders of Giants eh David ;)

I can help with the doc if you like, perhaps download the diff file
from the tracker, apply it and give it back for you to apply on your
patch?


-- 
--

James

[lemzwerg, 2012-01-10 06:29:38]

Thanks, David!

[lemzwerg, 2012-01-10 06:29:57]

http://codereview.appspot.com/5527058/diff/1/python/convertrules.py
File python/convertrules.py (right):

http://codereview.appspot.com/5527058/diff/1/python/convertrules.py#newcode3362
python/convertrules.py:3362: 
From an orthogonal point of view, those variables should be either named
`matchstring' and `matcharg' or `matchastring' and `matchanarg'...  It's not
really important, but I prefer the former.

[MikeSol, 2012-01-10 07:08:29]

LGTM.  Good work!

The only think I'd ask is that you change the markup syntax before pushing the
patch.  I think that, if the distinction between footnote and auto-footnote is
going to be eliminated, it needs to be categorical.

[dak, 2012-01-10 10:07:10]

On 2012/01/10 06:29:57, lemzwerg wrote:
> http://codereview.appspot.com/5527058/diff/1/python/convertrules.py
> File python/convertrules.py (right):
> 
>
http://codereview.appspot.com/5527058/diff/1/python/convertrules.py#newcode3362
> python/convertrules.py:3362: 
> From an orthogonal point of view, those variables should be either named
> `matchstring' and `matcharg' or `matchastring' and `matchanarg'...  It's not
> really important, but I prefer the former.

So would I, but then I did not remember whether I would be impeding on Python's
namespace.  I would have to check.

[dak, 2012-01-10 10:07:38]

On 2012/01/09 20:42:30, J_lowe wrote:
> Does this do anything to the
> \auto-footnote
> 
> command as well?

No.

[dak, 2012-01-10 10:19:54]

On 2012/01/10 07:08:29, MikeSol wrote:
> LGTM.  Good work!
> 
> The only think I'd ask is that you change the markup syntax before pushing the
> patch.  I think that, if the distinction between footnote and auto-footnote is
> going to be eliminated, it needs to be categorical.

Optional arguments are not implemented for markup functions, so no can do.  It
is an obvious contender once they are.  As a stopgap measure, one might think
about using ##f or something to that effect instead of \default.  autoFootnote
and auto-footnote have been different before, so I don't consider it really
urgent to squeeze this in while markup functions have not received the
treatment.

[Reinhold, 2012-01-10 12:59:21]

LGTM.

From a lazy user's POV, I don't like that I now have to use \default for
auto-numbering (which is th typical case)...
But then, one can always define one's own music function that takes care of
that. So no objection from my side.

http://codereview.appspot.com/5527058/diff/1/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):

http://codereview.appspot.com/5527058/diff/1/Documentation/notation/input.ite...
Documentation/notation/input.itely:1141: @funindex \footnote
Remove duplicate...

[dak, 2012-01-10 13:18:03]

On 2012/01/10 12:59:21, Reinhold wrote:
> LGTM.
> 
> From a lazy user's POV, I don't like that I now have to use \default for
> auto-numbering (which is th typical case)...

It is the same as with \mark (we don't have \autoMark either).  One might
consider moving the footnote mark argument to last position, but the footnote
text is potentially long, and so it better comes last so that one is not
surprised at what follows afterwards.

There are too many arguments either way for comfort.  But I think that making
this comparable to \mark is sensible.

[dak, 2012-01-10 13:28:46]

On 2012/01/10 13:18:03, dak wrote:
> On 2012/01/10 12:59:21, Reinhold wrote:
> > LGTM.
> > 
> > From a lazy user's POV, I don't like that I now have to use \default for
> > auto-numbering (which is th typical case)...
> 
> It is the same as with \mark (we don't have \autoMark either).  One might
> consider moving the footnote mark argument to last position

Actually, one could juggle the order of arguments around such that the optional
arguments can't be confused with the next argument.  Like putting the footnote
mark first, position next, Grob spec next, footnote text last.  In that manner,
you could leave off either Grob spec or footnote mark without needing to say
\default.  And even if one writes \default for autonumbering, having it directly
after the command will look more like \mark.

[janek, 2012-01-11 05:11:39]

There are some duplications in the docs now.
(LBTM?)

http://codereview.appspot.com/5527058/diff/1/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):

http://codereview.appspot.com/5527058/diff/1/Documentation/notation/input.ite...
Documentation/notation/input.itely:1053: The command @code{\autoFootnoteGrob}
must come @emph{before} the grob
Shouldn't @code{\autoFootnoteGrob} be changed to @code{\footnote}, with a
mention of \default too?

Similar below

http://codereview.appspot.com/5527058/diff/1/Documentation/notation/input.ite...
Documentation/notation/input.itely:1070: To annotate chorded notes, the
@code{\autoFootnote} must come
Shouldn't @code{\autoFootnote} be changed to @code{\footnote}, with a mention of
\default too?

http://codereview.appspot.com/5527058/diff/1/Documentation/notation/input.ite...
Documentation/notation/input.itely:1146: for individual grobs (and
@code{\markup} when using @code{TextScripts}).
"there are 2 commands, \footnote and \footnote"...

[dak, 2012-01-11 06:57:48]

On 2012/01/11 05:11:39, janek wrote:
> There are some duplications in the docs now.
> (LBTM?)

"The notation manual has not been revised yet."

Since I am currently doing the convert-ly rules for juggling the argument order
and this will, obviously, also affect the manual both with respect to
autoconversion as well as text sense, I am saving this for later.  Of course,
I'll be happy if someone else does the work on the NR, though of course the
Scheme function documentation itself should match the code right away.

[pkx166h, 2012-01-11 11:45:19]

On 2012/01/11 06:57:48, dak wrote:
> On 2012/01/11 05:11:39, janek wrote:
> > There are some duplications in the docs now.
> > (LBTM?)
> 
> "The notation manual has not been revised yet."
> 
> Since I am currently doing the convert-ly rules for juggling the argument
order
> and this will, obviously, also affect the manual both with respect to
> autoconversion as well as text sense, I am saving this for later.  Of course,
> I'll be happy if someone else does the work on the NR, though of course the
> Scheme function documentation itself should match the code right away.

I've created

http://code.google.com/p/lilypond/issues/detail?id=2213 so I'll work on the NR
as I did all the \footnote Doc in the first place.

I am assuming you still have to include your documentation edits in the patch so
that the docs compile?

Otherwise we will have a bit of a disconnect with the code and documentation
until I push my patch. I'll try to get this done asap.

On a 'merging' note, should I take the diff file from this tracker for the
input.itely and use that as my base so that I don't end up with 'unable to
apply' patch type messages on myside if I work from the *itely as it is in
master?

[dak, 2012-01-11 12:03:41]

On 2012/01/11 11:45:19, J_lowe wrote:
> I've created
> 
> http://code.google.com/p/lilypond/issues/detail?id=2213 so I'll work on the NR
as I did all the \footnote Doc in the first place.
> 
> I am assuming you still have to include your documentation edits in the patch
so that the docs compile?

Nope, the last batch of running convert-ly appears to cover this.

The documentation compiles, it just talks nonsense in the text.

> On a 'merging' note, should I take the diff file from this tracker for the
input.itely and use that as my base so that I don't end up with 'unable to
apply' patch type messages on myside if I work from the *itely as it is in
master?

Since I don't expect significant changes anymore, this sounds reasonable.  If
you wanted to be safer than that, your patch would have to be sorted into the
series _before_ running update-with-convert-ly.  But I would prefer doing the
two steps in this review as a single commit, and if we bounce the doc changes
between our private repositories, this will just complicate matters.

[janek, 2012-01-11 12:13:15]

2012/1/11  <dak@gnu.org>:
> On 2012/01/11 05:11:39, janek wrote:
>>
>> There are some duplications in the docs now.
>> (LBTM?)
>
>
> "The notation manual has not been revised yet."

Ok, i misunderstood.  Sorry.