Re: Doc indexing confusion
http://lists.gnu.org/archive/html/lilypond-devel/2005-05/msg00200.html
Mark Polesky wrote Tuesday, December 21, 2010 5:12 AM
In texinfo:
@cindex foo-- add foo to the concept index
@findex foo-- add foo to the function index
@kindex foo-- add foo to the keystroke index
@printindex cp -- print the concept index
@printindex fn -- print the function index
@printindex ky -- print the keystroke index
In Documentation/common-macros.itexi, @funindex is defined:
@macro funindex {TEXT}
@findex \TEXT\
@kindex \TEXT\
@c
@end macro
The last two appendices of the NR are:
E. LilyPond command index
F. LilyPond index
In Documentation/notation.tely:
@printindex ky -- makes appendix E. "command index"
@printindex cp -- makes appendix F. "index"
There is some discussion of the rationale behind the
indices in
http://lists.gnu.org/archive/html/lilypond-devel/2005-05/msg00200.html
Questions:
1) Everything marked with a @funindex in the docs ends up in
*both* NR indices. How and why do these items end up in
appendix F?
@syncodeindex merges two indices. This is called by
the @lilyTitlePage macro to place both f and v indices
into the c index. This in turn is called in the .tely
file for each manual.
There is some discussion of the original rationale
behind the indices in
http://lists.gnu.org/archive/html/lilypond-devel/2005-05/msg00200.html
2) Why do we need @funindex? Why don't we just use these:
@findex
@printindex fn
I think it is to get round the vagaries of @syncodeindex. See
http://lists.gnu.org/archive/html/lilypond-devel/2006-05/msg00275.html
Graham might remember ...
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: More NR and LM additions based on user emails (issue3705042)
Hello, Is this OK to give someone a patch to push? James http://codereview.appspot.com/3705042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: addendum to \break in examples
On Tue, Dec 21, 2010 at 12:33 AM, Graham Percival wrote: > % bad: > c2 d e d | c d e d | c d e d > > % good: > c2 d e d | e f g f | g a b a > > % or even: > c2 d e d | e f g f | g f e d > \break > c2 d e d | e f g f | g c, e d | c1 Why not use quarter-notes? > I don't encourage accidentals or dotted rhythms, but there's a lot > that we can do with simple melodies in C major (or A minor) to > make it easier for people to recognize a particular bar of input > to a particular bar of output. I'm not sure I understand, but: are you suggesting that we match line-breaks in the input with line-breaks in the output? Speaking of simple melodies, you might disapprove of my latest doc addition :-) Cheers, Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] make post-event music functions direction-aware (issue3743043)
On 2010/12/20 23:18:37, Neil Puttock wrote: Simply set 'direction inside the parser rule itself following the function evaluation. Hi Neil, something like that? (see new patch set) Cheers, Valentin. http://codereview.appspot.com/3743043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: More NR and LM additions based on user emails (issue3705042)
Looks fine to me, but then you've used the wording I suggested, so it would, wouldn't it :) Best wait for someone else to approve. Trevor http://codereview.appspot.com/3705042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: More NR and LM additions based on user emails (issue3705042)
On 2010/12/21 15:21:29, Trevor Daniels wrote: Looks fine to me, but then you've used the wording I suggested, so it would, wouldn't it :) Best wait for someone else to approve. I believe that Graham and I have both approved it. Carl http://codereview.appspot.com/3705042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc indexing confusion
On Mon, Dec 20, 2010 at 09:12:11PM -0800, Mark Polesky wrote:
> In texinfo:
> @cindex foo-- add foo to the concept index
We use this one.
I think Trevor pretty much explained this stuff. I have a fever
so I'm thinking straight and I might have missed something below.
> @findex foo-- add foo to the function index
> @kindex foo-- add foo to the keystroke index
> @printindex cp -- print the concept index
> @printindex fn -- print the function index
> @printindex ky -- print the keystroke index
We don't use these directly.
> In Documentation/common-macros.itexi, @funindex is defined:
> @macro funindex {TEXT}
> @findex \TEXT\
> @kindex \TEXT\
> @c
> @end macro
Yes.
> The last two appendices of the NR are:
> E. LilyPond command index
> F. LilyPond index
>
> In Documentation/notation.tely:
> @printindex ky -- makes appendix E. "command index"
> @printindex cp -- makes appendix F. "index"
>
> Questions:
> 1) Everything marked with a @funindex in the docs ends up in
>*both* NR indices. How and why do these items end up in
>appendix F?
Because @funindex calls both @findex and @kindex, and we merge a
copy of @findex with @kindex.
> 2) Why do we need @funindex? Why don't we just use these:
> @findex
> @printindex fn
Because then anything in appendix E won't appear in appendix F,
and (at some point in our past) there was a feeling that commands
should be printed in both indices.
>I see that @findex is used in the IR to generate
> appendix A.2 Function index
>
>...but that shouldn't affect the NR, right?
Correct.
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: addendum to \break in examples
Valentin Villenave wrote: > Speaking of simple melodies, you might disapprove of my > latest doc addition :-) "I Saw Mommy Kissing Santa Claus", à la Messiaen? - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: addendum to \break in examples
On Tue, Dec 21, 2010 at 6:55 PM, Mark Polesky wrote: > "I Saw Mommy Kissing Santa Claus", à la Messiaen? Almost. http://tinyurl.com/3a86bxy (Didn't know this one, thanks for the discovery!) Cheers, Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
LM 4.4.2 \fooDown \fooUp (and how about \textDown?)
Greetings everybody, hi Trevor, I've been looking at the LM 4.4.2 Placement of objects > Within-staff objects, and I'm not sure we want to use "Down/Left" and "Up/Right" in the table. Yes, we all know that -1 and 1 may respectively mean either "down" or "left" and either "up" or "right", but in this table we're *only* documenting objects that are aligned vertically! Oh, and by the way: we have \textSpannerDown for text spanners, but not \textDown for simple TextScript objects (that are quite likely to be needed by new users). Anyone against adding textDown, textUp, textNeutral? Cheers, Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] make post-event music functions direction-aware (issue3743043)
On 2010/12/20 16:22:30, Carl wrote: IMO, go ahead and set the neutral direction. If it passes make check, then call it good. Hi Carl, actually, whilst it does pass make check, it breaks... all of my own scores! I use the following function: filterDirections= #(define-music-function (parser location music) (ly:music?) (music-filter (lambda (x) (not (null? (ly:music-property x 'direction music)) that allows me to discriminate dynamics that have an explicit direction (even a neutral one) from those who don't. Of course, I can fix my own code accordingly. But it shows that this change may not be entirely harmless for everybody. Cheers, Valentin http://codereview.appspot.com/3743043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] make post-event music functions direction-aware (issue3743043)
On 2010/12/21 20:45:42, Valentin Villenave wrote: On 2010/12/20 16:22:30, Carl wrote: actually, whilst it does pass make check, it breaks... all of my own scores! I can't understand why you don't want to push a patch that breaks all your scores... ;-) Does this latest patch break your scores? I use the following function: filterDirections= #(define-music-function (parser location music) (ly:music?) (music-filter (lambda (x) (not (null? (ly:music-property x 'direction music)) that allows me to discriminate dynamics that have an explicit direction (even a neutral one) from those who don't. What is the logical distinction you want to make between a neutral direction and the lack of an explicit direction? I'm a bit nervous about using an undocumented lack of a direction setting as a signal to do something. It seems to me to be not very robust. Thanks, Carl http://codereview.appspot.com/3743043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] make post-event music functions direction-aware (issue3743043)
On 2010/12/21 21:24:52, Carl wrote:
I can't understand why you don't want to push a patch that breaks all
your
scores... ;-)
Does this latest patch break your scores?
It does, since the 'direction property is never left null (I can work
around it, though. But at first I did feel a bit shocked, I must say :-)
What is the logical distinction you want to make between a neutral
direction and
the lack of an explicit direction?
I'm a bit nervous about using an undocumented lack of a direction
setting as a
signal to do something. It seems to me to be not very robust.
It may not be robust, but it's actually very convenient.
Please bear with me for a little while, I'll try to explain.
The nicest way to write a piano part with centered dynamics is
currently:
\new PianoStaff <<
\new Staff \rightHand
\new Dynamics \myDynamics
\new Staff \leftHand
The downside is: writing dynamics separately in a variable filled with
skips and rests, is quite cumbersome. I much prefer writing the dynamics
on the fly with the right- or left-hand music (or ideally, both). So,
what if I could somehow extract the dynamics from these music
expressions and gather them in the Dynamics context?
\new PianoStaff <<
\new Staff \removeDynamics \rightHand
\new Dynamics \keepOnlyDynamics << \rightHand \\ \leftHand >>
\new Staff \removeDynamics \leftHand
http://repo.or.cz/w/opus_libre.git/blob/HEAD:/lib/80-buildskel.scm#l174
http://repo.or.cz/w/opus_libre.git/blob/HEAD:/lib/80-buildskel.scm#l81
I *could* do this only with contexts and engravers. However, a new issue
arises: sooner or later, I'm bound to have to print some dynamics above
the upper staff, or below the lower staff (or even: below the upper
staff, *but* not vertically centered, but instead closer to the relevant
staff). Which I won't be able to do if I've removed the
Dynamics_engraver from the Staff context. What to do?
There we go: I have to use a music-filter, much like \keepWithTag or
\removeWithTag, only it will check for explicit directions.
http://repo.or.cz/w/opus_libre.git/blob/HEAD:/lib/libdynamic.scm#l58
This way, I can do:
rightHand = \relative c' {
c1\f %% This will be sent to the Dynamics context
c^\f %% This will be printed above the upper staff
c_\f %% This will be printed below the staff, but closer to the upper
staff.
c\< %% I can even begin a crescendo here...
c
}
leftHand = \relative c { \clef bass
c1 c c c c\ff %% ... And finish it here.
}
It's a hell of a hack (as is my whole framework anyway), and it does add
a considerable overhead. But boy, do my scores look good! :-)
Cheers,
Valentin.
http://codereview.appspot.com/3743043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] make post-event music functions direction-aware (issue3743043)
On 2010/12/21 14:19:56, Valentin Villenave wrote:
something like that? (see new patch set)
Almost there, but you're still setting 'direction unconditionally
instead of checking first, i.e.,
$$ = run_music_function (PARSER, $2);
if ($1)
{
unsmob $$ and set direction
}
Cheers,
Neil
http://codereview.appspot.com/3743043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LM 4.4.2 \fooDown \fooUp (and how about \textDown?)
On 12/21/10 1:14 PM, "Valentin Villenave" wrote: > Greetings everybody, hi Trevor, > > I've been looking at the LM 4.4.2 Placement of objects > Within-staff > objects, and I'm not sure we want to use "Down/Left" and "Up/Right" in > the table. Yes, we all know that -1 and 1 may respectively mean either > "down" or "left" and either "up" or "right", but in this table we're > *only* documenting objects that are aligned vertically! I agree with you here. I think it should be Down and Up in the table headings. > > Oh, and by the way: we have \textSpannerDown for text spanners, but > not \textDown for simple TextScript objects (that are quite likely to > be needed by new users). Anyone against adding textDown, textUp, > textNeutral? Why should we add \textDown, \textUp, and \textNeutral? TextScript is markup text, IIUC, and markup text attached to a note is always preceded by ^ - or _, isn't it? It seems to me that having special commands will just cause confusion. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] make post-event music functions direction-aware (issue3743043)
On 2010/12/21 22:12:46, Valentin Villenave wrote: It does, since the 'direction property is never left null (I can work around it, though. But at first I did feel a bit shocked, I must say :-) Use ly:dir? instead of (not (null? ...). Cheers, Neil http://codereview.appspot.com/3743043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] make post-event music functions direction-aware (issue3743043)
On 2010/12/21 22:21:38, Neil Puttock wrote: Almost there, but you're still setting 'direction unconditionally instead of checking first, i.e., Done (new patch). However, I can't really understand how this condition could ever be false. What kind of input could trigger the parser rule without actually containing a proper direction? Cheers, Valentin. http://codereview.appspot.com/3743043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] make post-event music functions direction-aware (issue3743043)
On 2010/12/21 22:27:43, Neil Puttock wrote: Use ly:dir? instead of (not (null? ...). Duh. Nice catch, thanks! Cheers, V. http://codereview.appspot.com/3743043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] make post-event music functions direction-aware (issue3743043)
On 2010/12/21 22:34:23, Valentin Villenave wrote:
Done (new patch). However, I can't really understand how this
condition could
ever be false. What kind of input could trigger the parser rule
without actually
containing a proper direction?
script_dir:
'_' { $$ = DOWN; }
| '^' { $$ = UP; }
| '-' { $$ = CENTER; }
;
CENTER = 0, so is always false.
Cheers,
Neil
http://codereview.appspot.com/3743043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] make post-event music functions direction-aware (issue3743043)
On 2010/12/21 22:45:53, Neil Puttock wrote: CENTER = 0, so is always false. Oh, I didn't know 0 was false, in Guile you can have something like: guile> (define a 0) guile> (if a (display "true\n")) true guile> (yes it's silly, but remember that the only things about programming I know, I learned with LilyPond!) Do you think I can push this patch now? (Not sure where to document it, though. Probably somewhere in the Extending manual.) Cheers, Valentin. http://codereview.appspot.com/3743043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Patch] make post-event music functions direction-aware (issue3743043)
On 2010/12/21 22:56:05, Valentin Villenave wrote: Oh, I didn't know 0 was false, in Guile you can have something like: guile> (define a 0) guile> (if a (display "true\n")) true guile> Yep, Scheme is strict about #f: it's not equal to any other object. Do you think I can push this patch now? (Not sure where to document it, though. Probably somewhere in the Extending manual.) I don't think you need to copy the function evaluation result into a new SCM object, but apart from that it LGTM. Cheers, Neil http://codereview.appspot.com/3743043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Documentation of Dynamics context and postfix dynamics changes (issue3732046)
I posted a revised patch under my own login, directly from the system that compiled it,at http://codereview.appspot.com/3743045/ Carl, the C G was clear enough that I had no trouble going straight to Rietveld, but I can send (or you can grab) the revised patch to post under this issue# if you prefer. The revision changes less than this one did, but it gets the job done and complies, I'm pretty sure, with doc style. http://codereview.appspot.com/3732046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
DOC: NR Dynamics context and postfix dynamics (issue3743045)
This looks even better to me. Thanks!
I have a few comments below.
I'm delighted to have you manage the review and updates for this patch.
When it's time to apply the patch, if you'll create a patch using
git-format-patch, and email it to somebody to push (maybe Trevor
Daniels, or me), then we'll be able to commit it with you as the
author.
The snippets in input/regression/ are *not* part of the documentation;
they're just regression tests. If a snippet is to become part of the
documentation, and is not included inline in the file, then you'll want
to have a snippet intended for documentation use in
Documentation/snippets/new.
Thanks,
Carl
http://codereview.appspot.com/3743045/diff/1/Documentation/notation/expressive.itely
File Documentation/notation/expressive.itely (right):
http://codereview.appspot.com/3743045/diff/1/Documentation/notation/expressive.itely#newcode366
Documentation/notation/expressive.itely:366: Textual crescendo marks
begin with @code{\cresc}
We can even get shorter and simpler here, by saying
"Textual dynamic changes with extender lines can be created using
postfix functions:"
The example shows everything we need to know; we don't need to explain
the code in the text.
http://codereview.appspot.com/3743045/diff/1/Documentation/notation/expressive.itely#newcode392
Documentation/notation/expressive.itely:392: Textual marks can also be
produced by @code{\<} and @code{\>}:
Maybe this should say something like
"Textual markings for dynamic changes can also replace hairpins,
although
this usage is deprecated:"
The key issue here is that we're using \*Text* to replace a standard
hairpin.
http://codereview.appspot.com/3743045/diff/1/Documentation/notation/keyboards.itely
File Documentation/notation/keyboards.itely (right):
http://codereview.appspot.com/3743045/diff/1/Documentation/notation/keyboards.itely#newcode84
Documentation/notation/keyboards.itely:84: see @ref{Dynamics}, between
the two @code{Staff} contexts
References should be at the end of sentences where possible.
http://codereview.appspot.com/3743045/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
