Re: make translation-status fails
2011/2/16 Jean-Charles Malahieude : > Le 16/02/2011 13:19, Francisco Vila disait : >> >> 2011/2/16 Francisco Vila: >> BTW does >> >> LANG=whatever date -u >> >> work for you? for whatever = fr, de etc? >> > > [jcharles@localhost ~]$ LANG=de_DE.utf8 date -u > Mi 16. Feb 18:52:37 UTC 2011 > [jcharles@localhost ~]$ LANG=de date -u > Wed Feb 16 18:53:21 UTC 2011 > [jcharles@localhost ~]$ LANG=de_DE.utf8 date -u > Mi 16. Feb 18:53:24 UTC 2011 > [jcharles@localhost ~]$ LANG=es_ES.utf8 date -u > mié feb 16 18:53:39 UTC 2011 > [jcharles@localhost ~]$ date -u > mer. févr. 16 18:54:02 UTC 2011 > [jcharles@localhost ~]$ LANG=fr date -u > Wed Feb 16 18:54:14 UTC 2011 > [jcharles@localhost ~]$ LANG=fr_FR.utf8 date -u > mer. févr. 16 18:54:25 UTC 2011 > [jcharles@localhost ~]$ > > > Found after having > env | grep LANG Thank you. Therefore, the code that pretends to build a localized date string at the translation status page, is wrong (or useless), and it looks a bit more complicated to infer the value of LANG from the lang code we use in the build. I could 'manually' add the code and values but not sure if it worths the effort. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: T1247 - Conditionally do (use-modules (ice-9 curried-definitions)) if running with Guile V2, (issue2219044)
Hi Ian, Please see my new comment regarding this patch (below). Thanks, Patrick http://codereview.appspot.com/2219044/diff/25001/scm/display-lily.scm File scm/display-lily.scm (right): http://codereview.appspot.com/2219044/diff/25001/scm/display-lily.scm#newcode34 scm/display-lily.scm:34: Jan recently removed all of the curried definitions that were affected by this conditional (use-modules ...) call. I just compiled LilyPond (and the patch queue from my "guile" branch) against Guile 2.0 *without* this part of your patch, and I didn't run into any issues. In other words, you can safely remove this chunk from your patch. http://codereview.appspot.com/2219044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: guile 2.0.0 out
On Wed, Feb 16, 2011 at 7:22 PM, Graham Percival wrote: > On Wed, Feb 16, 2011 at 07:08:29PM -0800, Patrick McCarty wrote: > >> I have a patch queue with >> (potential) fixes for LilyPond so that we can support both Guile 1.8 >> and 2.0. > > Great! Comment 5 of > http://code.google.com/p/lilypond/issues/detail?id=1247 > is no longer valid? Yeah, I'm pretty sure Jan's recent commit in master (05514c83a49dd) removed the rest of the currying functions that Ian and I were puzzling over. The reason I'm only "pretty sure" is because I will be doing further tests tonight to see if that's really true. I'll comment on Ian's patch after I test-compile 2.0 without it. > I wasn't trying to force us to drop guile 1.8; I was just making > sure that we agreed that guile 2.0 wasn't going into 2.14, and > fishing for comments like "we can support both Guile 1.8 and 2.0." > :) I agree with you there. I intend to continue working on backward-compatibility patches for 2.14 that will work on both Guile 1.8 and 2.0, but the Guile-2.0-specific patches (if needed) will have to wait for 2.15. I only slightly misunderstood your email after all... ;) Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add modal transformations provided by Mike Ellis (issue4079064)
Still works well for me, including the new bits.
Some late suggestions on the docs that you can take or leave.
http://codereview.appspot.com/4079064/diff/7001/Documentation/notation/pitches.itely
File Documentation/notation/pitches.itely (right):
http://codereview.appspot.com/4079064/diff/7001/Documentation/notation/pitches.itely#newcode861
Documentation/notation/pitches.itely:861: A scale of any length and with
any intervals may be specified:
"An ascending scale of any length ..."
The octaves are linked smoothly if the scale is ascending.
Jumps of an octave in the input scale will be a common first-time
mistake, so the \relative command in the example is very good idea. It
might be worth ten more words.
"The @code{relative} command is useful for creating a continuous scale:"
http://codereview.appspot.com/4079064/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: guile 2.0.0 out
On Wed, Feb 16, 2011 at 07:08:29PM -0800, Patrick McCarty wrote: > On Wed, Feb 16, 2011 at 10:04 AM, Graham Percival > wrote: > > > > I don't see a need to support both guile 1.8.x and guile 2.0.x at > > the same time -- as far as I'm concerned, we can drop any > > guile-1.x-isms as soon as 2.15 begins. > > Uh, I'm not sure what you mean here. I mean that my personal opinion, at the moment, subject to rational arguments and/or additional information, is that we do not need to support guile 1.8. > I have a patch queue with > (potential) fixes for LilyPond so that we can support both Guile 1.8 > and 2.0. Great! Comment 5 of http://code.google.com/p/lilypond/issues/detail?id=1247 is no longer valid? > I don't think it's wise to drop support for Guile 1.8, as long as the > Guile developers continue to fix backward-compatibility issues with > the 2.0 series, just like they have in the 1.9 series. Ok. Well, if the two can co-exist, then we might as well keep both; no point even considering whether we "need" guile 1.8 or not. I wasn't trying to force us to drop guile 1.8; I was just making sure that we agreed that guile 2.0 wasn't going into 2.14, and fishing for comments like "we can support both Guile 1.8 and 2.0." :) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add dots to tocItemMarkup (issue4182056)
Looks good. I had one comment. Feel free to add an entry to the changelog. It's done by editing the file Documentation/changes.tely Thanks, Carl http://codereview.appspot.com/4182056/diff/7001/scm/define-markup-commands.scm File scm/define-markup-commands.scm (right): http://codereview.appspot.com/4182056/diff/7001/scm/define-markup-commands.scm#newcode3403 scm/define-markup-commands.scm:3403: (define-markup-command (pattern layout props pattern count space) Now that I see it written -- should there be a direction argument for pattern? Or at least should we document that it's a horizontal repeat? http://codereview.appspot.com/4182056/diff/7001/scm/define-markup-commands.scm#newcode3416 scm/define-markup-commands.scm:3416: (if (zero? i) Nicely done! http://codereview.appspot.com/4182056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: guile 2.0.0 out
On Wed, Feb 16, 2011 at 10:04 AM, Graham Percival wrote: > > I don't see a need to support both guile 1.8.x and guile 2.0.x at > the same time -- as far as I'm concerned, we can drop any > guile-1.x-isms as soon as 2.15 begins. Uh, I'm not sure what you mean here. I have a patch queue with (potential) fixes for LilyPond so that we can support both Guile 1.8 and 2.0. I don't think it's wise to drop support for Guile 1.8, as long as the Guile developers continue to fix backward-compatibility issues with the 2.0 series, just like they have in the 1.9 series. -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add dots to tocItemMarkup (issue4182056)
Maybe add \pattern to the changelog ? http://codereview.appspot.com/4182056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add dots to tocItemMarkup (issue4182056)
Changes done ! It is more clean now. I'm not sure if the commands are in the right categories. I also noticed numerous commands have @code instead of @var and vice versa in their descriptions. Center-align's args or fill-line's line-width for example. Should I do a small patch to fix these ? Regards, Bertrand http://codereview.appspot.com/4182056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix 1229 Ensure space around prefatory matter (issue4187043)
Keith OHara wrote Wednesday, February 16, 2011 8:54 PM On Wed, 16 Feb 2011 08:08:10 -0800, wrote: On 2011/02/15 18:36:06, Keith wrote: If there is /any/ protrusion on the lyrics side of the staff, anywhere in the score, then the PaperColumn skylines used for note-spacing are built as if lyrics are spaced to clear that protrusion. The bar-lines then slide past this assumed position of lyrics. Actually it would be quite common for a vocal piece to have no soprano note above f'', or no bass note below g, . The stems on mid-staff notes still protrude in that case, letting the bar-lines slide past lyrics. Only in the case of a completely clear bottom edge of the staff, does this patch expand the bar to fit LyricText. Ah, of course. No problem then. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: guile 2.0.0 out
Graham Percival writes: > On Wed, Feb 16, 2011 at 09:19:01PM +0100, David Kastrup wrote: >> Graham Percival writes: >> >> > I don't see a need to support both guile 1.8.x and guile 2.0.x at the >> > same time -- as far as I'm concerned, we can drop any guile-1.x-isms >> > as soon as 2.15 begins. >> >> As long as guile is not included with Lilypond, supporting the last >> stable version in reasonably up-to-date operating system distributions >> is definitely going to help maintain a healthy developer base. > > Hence my absolute insistance on having the required version of > guile 2.x in lilydev. Admittedly, I overlooked people using linux > natively. My initial guess is that such people (including myself) > are more than capable of compiling and install guile from source, If your only use of guile-dev is Lilypond, maybe. Other than that, things are going to become a nuisance. > I know that David already knows this, but for the benefit of > anybody else reading this email who might be confused: lilypond > GUB includes guile, so we're not talking about people who want to > test 2.15. This only affects people wanting to compile lilypond > from source, i.e. developers and contributors. That's what I mean with "maintain a healthy developer base". -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix 1229 Ensure space around prefatory matter (issue4187043)
On Wed, 16 Feb 2011 08:08:10 -0800, wrote: On 2011/02/15 18:36:06, Keith wrote: If there is /any/ protrusion on the lyrics side of the staff, anywhere in the score, then the PaperColumn skylines used for note-spacing are built as if lyrics are spaced to clear that protrusion. The bar-lines then slide past this assumed position of lyrics. Actually it would be quite common for a vocal piece to have no soprano note above f'', or no bass note below g, . The stems on mid-staff notes still protrude in that case, letting the bar-lines slide past lyrics. Only in the case of a completely clear bottom edge of the staff, does this patch expand the bar to fit LyricText. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: guile 2.0.0 out
On Wed, Feb 16, 2011 at 09:19:01PM +0100, David Kastrup wrote: > Graham Percival writes: > > > I don't see a need to support both guile 1.8.x and guile 2.0.x at the > > same time -- as far as I'm concerned, we can drop any guile-1.x-isms > > as soon as 2.15 begins. > > As long as guile is not included with Lilypond, supporting the last > stable version in reasonably up-to-date operating system distributions > is definitely going to help maintain a healthy developer base. Hence my absolute insistance on having the required version of guile 2.x in lilydev. Admittedly, I overlooked people using linux natively. My initial guess is that such people (including myself) are more than capable of compiling and install guile from source, but this is certainly a point to consider when the dev/guile branch is actually ready for merging. I know that David already knows this, but for the benefit of anybody else reading this email who might be confused: lilypond GUB includes guile, so we're not talking about people who want to test 2.15. This only affects people wanting to compile lilypond from source, i.e. developers and contributors. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: guile 2.0.0 out
Graham Percival writes: > I don't see a need to support both guile 1.8.x and guile 2.0.x at the > same time -- as far as I'm concerned, we can drop any guile-1.x-isms > as soon as 2.15 begins. As long as guile is not included with Lilypond, supporting the last stable version in reasonably up-to-date operating system distributions is definitely going to help maintain a healthy developer base. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make translation-status fails
Le 16/02/2011 13:19, Francisco Vila disait : 2011/2/16 Francisco Vila: BTW does LANG=whatever date -u work for you? for whatever = fr, de etc? [jcharles@localhost ~]$ LANG=de_DE.utf8 date -u Mi 16. Feb 18:52:37 UTC 2011 [jcharles@localhost ~]$ LANG=de date -u Wed Feb 16 18:53:21 UTC 2011 [jcharles@localhost ~]$ LANG=de_DE.utf8 date -u Mi 16. Feb 18:53:24 UTC 2011 [jcharles@localhost ~]$ LANG=es_ES.utf8 date -u mié feb 16 18:53:39 UTC 2011 [jcharles@localhost ~]$ date -u mer. févr. 16 18:54:02 UTC 2011 [jcharles@localhost ~]$ LANG=fr date -u Wed Feb 16 18:54:14 UTC 2011 [jcharles@localhost ~]$ LANG=fr_FR.utf8 date -u mer. févr. 16 18:54:25 UTC 2011 [jcharles@localhost ~]$ Found after having env | grep LANG HTH, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make translation-status fails
Le 16/02/2011 13:19, Francisco Vila disait : 2011/2/16 Francisco Vila: Fixed in git, I hope. Still testing the build. OK succeeds here as well. Thanks for the chase! BTW does LANG=whatever date -u work for you? for whatever = fr, de etc? [jcharles@localhost ~]$ LANG=zh date -u Wed Feb 16 18:47:21 UTC 2011 [jcharles@localhost ~]$ LANG=cs date -u Wed Feb 16 18:47:26 UTC 2011 [jcharles@localhost ~]$ LANG=es date -u Wed Feb 16 18:47:31 UTC 2011 [jcharles@localhost ~]$ Cheers, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LSR and docs
On 2/16/11 11:15 AM, "Phil Holmes" wrote: > One of my first jobs hereabouts was adding snippets to the LSR and tagging > them with "docs". Could someone explain a) the significance of this and b) > how snippets are imported from the LSR into the LM and NR? I'm assuming the > two are linked, but not sure how. When makelsr.py is run, snippets are created from the LSR into Documentation/snippets. Individual snippets are included in the documentation by a @lilypondfile command. HTH, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LSR and docs
On Wed, Feb 16, 2011 at 06:15:03PM -, Phil Holmes wrote: > One of my first jobs hereabouts was adding snippets to the LSR and > tagging them with "docs". Could someone explain a) the significance > of this and It adds those snippets to the snippets-*-docs.tar.gz > b) how snippets are imported from the LSR into the LM > and NR? I'm assuming the two are linked, but not sure how. If you have any specific questions about the Contributor Guide's chapter on Snippets, then please be more specific. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
LSR and docs
One of my first jobs hereabouts was adding snippets to the LSR and tagging them with "docs". Could someone explain a) the significance of this and b) how snippets are imported from the LSR into the LM and NR? I'm assuming the two are linked, but not sure how. TIA. -- Phil Holmes Bug Squad ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add modal transformations provided by Mike Ellis (issue4079064)
LGTM
http://codereview.appspot.com/4079064/diff/7001/Documentation/notation/pitches.itely
File Documentation/notation/pitches.itely (right):
http://codereview.appspot.com/4079064/diff/7001/Documentation/notation/pitches.itely#newcode830
Documentation/notation/pitches.itely:830: left untransformed and a
warning given.}
I'd omit the "and a warning given". I mean, the warning will be
obvious, right? Just end with "... left untransformed."
http://codereview.appspot.com/4079064/diff/7001/input/regression/modal-transforms.ly
File input/regression/modal-transforms.ly (right):
http://codereview.appspot.com/4079064/diff/7001/input/regression/modal-transforms.ly#newcode11
input/regression/modal-transforms.ly:11: motive = {
I'm amused by the discrepancy between "motif" (in the docs) and "motive"
(in this regtest).
http://codereview.appspot.com/4079064/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
guile 2.0.0 out
Guile 2.0.0 is out. - no, there is no way that we'll try to add this for 2.14. Nice try! :) - changing to 2.0.0 could be done immediately after starting 2.15, as long as three conditions are met: 1. the regtests compile 2. the docs compile 3. the latest lilydev contains that version of guile I realize that working on #1 and #2 might uncover bugs in guile such that it'll only work with guile 2.0.1 or something like that. I suggest that we make a dev/guile-2.0 branch to work on the regtests and docs. I don't see a need to support both guile 1.8.x and guile 2.0.x at the same time -- as far as I'm concerned, we can drop any guile-1.x-isms as soon as 2.15 begins. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lyric alignment
On 2/16/11 9:31 AM, "Trevor Daniels" wrote: > > > Carl Sorensen wrote Saturday, February 12, 2011 9:09 PM > > >> I've attached a .ly file and its output. I think it gives the >> desired >> output. I'd welcome any comments. > > Looks useful. > > What about adding a third argument so 'staff-affinity > becomes set within the function too? > > \setLyricSpacing #25 #3 #DOWN etc I did that in a later version, but then I did even more work. I'm not sure it's needed. I'll put more work out later. > >> We could add the music function to ly/music-functions-init.ly, if >> you think >> we should. Alternatively, we could add it as-is to >> Documentation/snippets/new. > > I'd prefer to see it as a snippet for now. I suspect > it might take a little while for the new spacing controls > to settle down, and we might have further thoughts after > seeing more real user comments. I agree. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lyric alignment
Carl Sorensen wrote Saturday, February 12, 2011 9:09 PM I've attached a .ly file and its output. I think it gives the desired output. I'd welcome any comments. Looks useful. What about adding a third argument so 'staff-affinity becomes set within the function too? \setLyricSpacing #25 #3 #DOWN etc We could add the music function to ly/music-functions-init.ly, if you think we should. Alternatively, we could add it as-is to Documentation/snippets/new. I'd prefer to see it as a snippet for now. I suspect it might take a little while for the new spacing controls to settle down, and we might have further thoughts after seeing more real user comments. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc -- Clarify instructions on autobeam settings (issue4160048)
http://codereview.appspot.com/4160048/diff/11001/Documentation/notation/rhythms.itely#newcode2229 Documentation/notation/rhythms.itely:2229: changed, so that when the time signature is set the desired What about: ... changed, so that the desired beaming is always used for that time signature. ? then we avoid the dreaded "when" / "whenever". I'm happy with that. http://codereview.appspot.com/4160048/ Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix 1229 Ensure space around prefatory matter (issue4187043)
On 2011/02/15 18:36:06, Keith wrote: If there is /any/ protrusion on the lyrics side of the staff, anywhere in the score, then the PaperColumn skylines used for note-spacing are built as if lyrics are spaced to clear that protrusion. The bar-lines then slide past this assumed position of lyrics. Whether bar-lines avoiding lyrics is good thing or not, no-one is likely to ever see it in anything longer than a couple bars. Actually it would be quite common for a vocal piece to have no soprano note above f'', or no bass note below g, . Such a piece would have different behaviour for AT and SB wrt lyrics and bar lines. I think you're right to worry about this. Trevor http://codereview.appspot.com/4187043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add dots to tocItemMarkup (issue4182056)
http://codereview.appspot.com/4182056/diff/1/scm/define-markup-commands.scm File scm/define-markup-commands.scm (right): http://codereview.appspot.com/4182056/diff/1/scm/define-markup-commands.scm#newcode994 scm/define-markup-commands.scm:994: (define (nest-patterns pattern pattern-width distance count patterns) On 2011/02/16 14:26:45, Bertrand Bordage wrote: Ok. So, the input arguments will be "count", "pattern" and "distance" (in this order) ? Or just "count" and "pattern" ? As a markup function, they should be count, pattern, distance. The order doesn't really matter. My preference would be pattern, count, distance. http://codereview.appspot.com/4182056/diff/1/scm/define-markup-commands.scm#newcode1021 scm/define-markup-commands.scm:1021: } On 2011/02/16 14:26:45, Bertrand Bordage wrote: Maybe a smaller example ? Shall we see more possibilities ? With a \override #'(line-width . 50) for example. I think what's here is sufficient. But I wouldn't be opposed to a change. http://codereview.appspot.com/4182056/diff/1/scm/define-markup-commands.scm#newcode1032 scm/define-markup-commands.scm:1032: (x-offset (+ (* (- (- middle-width (* patterns-number period)) pattern-width) (/ (1+ dir) 2)) (abs (car pattern-x-extent) On 2011/02/16 14:26:45, Bertrand Bordage wrote: (my Lord ;o) ) ^^ -- Yikes! http://codereview.appspot.com/4182056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add dots to tocItemMarkup (issue4182056)
Reviewers: carl.d.sorensen_gmail.com,
Message:
A few questions.
http://codereview.appspot.com/4182056/diff/1/scm/define-markup-commands.scm
File scm/define-markup-commands.scm (right):
http://codereview.appspot.com/4182056/diff/1/scm/define-markup-commands.scm#newcode994
scm/define-markup-commands.scm:994: (define (nest-patterns pattern
pattern-width distance count patterns)
Ok. So, the input arguments will be "count", "pattern" and "distance"
(in this order) ? Or just "count" and "pattern" ?
With the property "word-space" instead of "distance"...
http://codereview.appspot.com/4182056/diff/1/scm/define-markup-commands.scm#newcode1021
scm/define-markup-commands.scm:1021: }
Maybe a smaller example ? Shall we see more possibilities ? With a
\override #'(line-width . 50) for example.
http://codereview.appspot.com/4182056/diff/1/scm/define-markup-commands.scm#newcode1032
scm/define-markup-commands.scm:1032: (x-offset (+ (* (- (- middle-width
(* patterns-number period)) pattern-width) (/ (1+ dir) 2)) (abs (car
pattern-x-extent)
It will be done (my Lord ;o) )
Description:
Add dots to tocItemMarkup
* scm/define-markup-commands.scm
New markup command : fill-with-pattern
* ly/toc-init.ly
Add dots to tocItemMarkup
Please review this at http://codereview.appspot.com/4182056/
Affected files:
M ly/toc-init.ly
M scm/define-markup-commands.scm
Index: ly/toc-init.ly
diff --git a/ly/toc-init.ly b/ly/toc-init.ly
index
dda4f31ab4d13250336decea7f2c3e57c87485e6..7f0a10622f7df7e230d8c2ef7e690443260286b3
100644
--- a/ly/toc-init.ly
+++ b/ly/toc-init.ly
@@ -26,9 +26,7 @@
\fill-line { \null "Table of Contents" \null }
\hspace #1
}
- tocItemMarkup = \markup \fill-line {
-\fromproperty #'toc:text \fromproperty #'toc:page
- }
+ tocItemMarkup = \markup \fill-with-pattern #1.5 #RIGHT "." \fromproperty
#'toc:text \fromproperty #'toc:page
}
#(define-markup-list-command (table-of-contents layout props) ()
Index: scm/define-markup-commands.scm
diff --git a/scm/define-markup-commands.scm b/scm/define-markup-commands.scm
index
5dbc5d2f5254b61bd4e3bd4c42b4143807501812..69c9122d3708ecda32142efd7b40bbe88d83ba76
100644
--- a/scm/define-markup-commands.scm
+++ b/scm/define-markup-commands.scm
@@ -991,6 +991,50 @@ If there are no arguments, return an empty stencil.
X)))
line-contents
+(define (nest-patterns pattern pattern-width distance count patterns)
+ (if (zero? count)
+ patterns
+ (nest-patterns pattern pattern-width distance (1- count) (markup
patterns #:with-dimensions (cons 0 pattern-width) '(0 . 0) pattern (markup
#:hspace distance)
+
+(define-markup-command (fill-with-pattern layout props period dir pattern
left right)
+ (number? number? markup? markup? markup?)
+ #:category align
+ #:properties ((word-space)
+(line-width))
+ "
+@cindex filling line with pattern
+Put @vars{left} and @vars{right} in a horizontal line of width
@vars{line-width} with a line of markups @vars{pattern} in between.
+Patterns are spaced apart by @vars{period}.
+Patterns are aligned to the @vars{dir} markup.
+@lilypond[verbatim, quote]
+\\markup \\column {
+ \"right-aligned :\"
+ \\fill-with-pattern #1.5 #RIGHT . first right
+ \\fill-with-pattern #1.5 #RIGHT . second right
+ \\null
+ \"center-aligned :\"
+ \\fill-with-pattern #2 #CENTER - left right
+ \\null
+ \"left-aligned :\"
+ \\fill-with-pattern #2.5 #LEFT : left first
+ \\fill-with-pattern #2.5 #LEFT : left second
+}
+@end lilypond"
+ (let* ((pattern-x-extent (ly:stencil-extent (interpret-markup layout
props pattern) X))
+ (pattern-width (interval-length pattern-x-extent))
+ (left-width (interval-length (ly:stencil-extent (interpret-markup
layout props left) X)))
+ (right-width (interval-length (ly:stencil-extent
(interpret-markup layout props right) X)))
+ (middle-width (- line-width (+ (+ left-width right-width) (*
word-space 2
+ (period (max period pattern-width))
+ (patterns-number (truncate (/ (- middle-width pattern-width)
period)))
+ (distance-between-patterns (- period pattern-width))
+ (patterns (markup))
+ (x-offset (+ (* (- (- middle-width (* patterns-number period))
pattern-width) (/ (1+ dir) 2)) (abs (car pattern-x-extent)
+(interpret-markup layout props
+ (markup left
+ #:override '(word-space . 0)
#:with-dimensions (cons 0 middle-width) '(0 . 0) #:translate (cons x-offset
0) (markup (nest-patterns pattern pattern-width distance-between-patterns
patterns-number patterns) pattern)
+ right
+
(define-markup-command (line layout props args)
(markup-list?)
#:category align
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: StaffGrouper properties does not apply to "second level" StaffGroup
On Mon, Feb 7, 2011 at 6:32 AM, Xavier Scheuer wrote:
> %% Reported on LilyPond French Users mailing list
> %%
> http://lilypond-french-users.1298960.n2.nabble.com/Arrangement-vertical-encore-une-petite-amelioration-tp5982503p5998593.html
> %%
> %% StaffGrouper properties does not apply to "second level" StaffGroup ,
> %% i.e. when this StaffGroup is itself contained in an "upper level"
> %% StaffGroup (or equivalent).
> %% Of course the problem is the same for all "Staff-groups"
> %% ( StaffGroup , ChoirStaff , PianoStaff , GrandStaff )
> %%
>
> \version "2.13.48"
>
> \score {
> <<
>\new StaffGroup <<
> \new Staff {
>c'1
> }
> \new StaffGroup \with {
>% this has no effet because
>% this StaffGroup is contained within a StaffGroup (or
> equivalent)
>\override StaffGrouper #'staffgroup-staff-spacing #'basic-distance =
> #20
> } <<
>\new Staff {
> c'1
>}
>\new Staff {
> c'1
>}
> >>
> \new Staff {
>c'1
> }
>>>
> >>
> }
>
>
> Cheers,
> Xavier
>
Thanks, Xavier -
Added as issue 1519 :
http://code.google.com/p/lilypond/issues/detail?id=1519
Ralph
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOC: NR 1.5.2 Multiple voices - part combining (issue4188056)
On 2011/02/16 06:08:03, Keith wrote: Looks good as it is, better if you can add one markup that Reinhold missed in the example. http://codereview.appspot.com/4188056/diff/1/Documentation/notation/simultaneous.itely File Documentation/notation/simultaneous.itely (right): http://codereview.appspot.com/4188056/diff/1/Documentation/notation/simultaneous.itely#newcode873 Documentation/notation/simultaneous.itely:873: from the left one of each pair of commands above. I had trouble understanding after the comma, but think the first part of the sentence says it all. AGree, Keith: I've trimmed it. http://codereview.appspot.com/4188056/diff/1/Documentation/notation/simultaneous.itely#newcode882 Documentation/notation/simultaneous.itely:882: \partcombineAutomatic c c | c^"auto" done, and thanks! http://codereview.appspot.com/4188056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Add dots to tocItemMarkup (issue4182056)
Looks very good. Just a couple more comments. Thanks, Carl http://codereview.appspot.com/4182056/diff/1/scm/define-markup-commands.scm File scm/define-markup-commands.scm (right): http://codereview.appspot.com/4182056/diff/1/scm/define-markup-commands.scm#newcode994 scm/define-markup-commands.scm:994: (define (nest-patterns pattern pattern-width distance count patterns) It might be even better if this were defined as a markup command, for example pattern-markup. Then anybody else (like me) could use it for making a repeating pattern of markups (like a LyricExtender for shape notes). http://codereview.appspot.com/4182056/diff/1/scm/define-markup-commands.scm#newcode1032 scm/define-markup-commands.scm:1032: (x-offset (+ (* (- (- middle-width (* patterns-number period)) pattern-width) (/ (1+ dir) 2)) (abs (car pattern-x-extent) Wrap to proper formatting at about 80 characters. http://codereview.appspot.com/4182056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 4167050: Changes the beam collision engraver to check for subsequent beams (Re: collision between beams and grace notes)
On Tue, Feb 15, 2011 at 6:58 PM, Neil Puttock wrote: > On 15 February 2011 20:02, m...@apollinemike.com > wrote: > >> I've uploaded a patch that takes grace notes (and other beams) into account. >> Keith - I'm not sure if this is the case. Currently, both my algorithm & >> Han-Wen's get the attached result without a modification to the beam >> collision engraver > > Here's a little Debussy excerpt for you. It doesn't work very well > with either patchset, though Han-Wen has the upper hand at the moment. > :) You can augment the region-size for the Han-Wen code to work correctly. I guess I should adapt region size more dynamically based on the difficulty of the beam. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make translation-status fails
2011/2/16 Francisco Vila : > > Fixed in git, I hope. Still testing the build. > BTW does LANG=whatever date -u work for you? for whatever = fr, de etc? -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add modal transformations provided by Mike Ellis (issue4079064)
> I've just uploaded the latest changes from Mike. These extend > modalInversion to permit inversions around a pivot between two notes in > the scale. > > There are also some minor changes suggested by Graham. > > Please review. LGTM > http://codereview.appspot.com/4079064/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add modal transformations provided by Mike Ellis (issue4079064)
I've just uploaded the latest changes from Mike. These extend modalInversion to permit inversions around a pivot between two notes in the scale. There are also some minor changes suggested by Graham. Please review. Trevor http://codereview.appspot.com/4079064/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make translation-status fails
2011/2/16 Francisco Vila : > I have discovered that > > translation[l] (last_updated_string) > > does not contain the %s format placeholder for l=zh > > I looks as an easy fix from here. Stay tuned. Fixed in git, I hope. Still testing the build. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make translation-status fails
2011/2/16 Francisco Vila : > 2011/2/16 Francisco Vila : >> This diff can temporarily make 'make translation-status' to succeed, >> without the last-updated string whose generation fails. > > I resend as an attachment. I have discovered that translation[l] (last_updated_string) does not contain the %s format placeholder for l=zh I looks as an easy fix from here. Stay tuned. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make translation-status fails
2011/2/16 Francisco Vila :
> This diff can temporarily make 'make translation-status' to succeed,
> without the last-updated string whose generation fails.
I resend as an attachment.
--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com
diff --git a/scripts/auxiliar/translations-status.py b/scripts/auxiliar/translations-status.py
index 2217463..5bef12b 100755
--- a/scripts/auxiliar/translations-status.py
+++ b/scripts/auxiliar/translations-status.py
@@ -724,7 +724,7 @@ open ('translations.itexi', 'w').write (main_status_page)
for l in enabled_languages:
date_time = buildlib.read_pipe ('LANG=%s date -u' % l)[0]
-updated = markup.paragraph (markup.emph (translation[l] (last_updated_string) % date_time))
+updated = "" # markup.paragraph (markup.emph (translation[l] (last_updated_string) % date_time))
texi_status = '\n'.join ([doc.translations[l].texi_status (markup)
for doc in master_docs
if l in doc.translations])
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make translation-status fails
2011/2/12 Jean-Charles Malahieude :
>>> make translation-status
>>
>> ...
>>>
>>> Traceback (most recent call last):
>>> File
>>> "/home/jcharles/GIT/Traduc/scripts/auxiliar/translations-status.py",
>>> line 727, in
>>> updated = markup.paragraph (markup.emph (translation[l]
>>> (last_updated_string) % date_time))
>>> TypeError: not all arguments converted during string formatting
>>
>> It fails for l = cs
This diff can temporarily make 'make translation-status' to succeed,
without the last-updated string whose generation fails.
diff --git a/scripts/auxiliar/translations-status.py
b/scripts/auxiliar/translations-status.py
index 2217463..5bef12b 100755
--- a/scripts/auxiliar/translations-status.py
+++ b/scripts/auxiliar/translations-status.py
@@ -724,7 +724,7 @@ open ('translations.itexi', 'w').write (main_status_page)
for l in enabled_languages:
date_time = buildlib.read_pipe ('LANG=%s date -u' % l)[0]
-updated = markup.paragraph (markup.emph (translation[l]
(last_updated_string) % date_time))
+updated = "" # markup.paragraph (markup.emph (translation[l]
(last_updated_string) % date_time))
texi_status = '\n'.join ([doc.translations[l].texi_status (markup)
for doc in master_docs
if l in doc.translations])
--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOC: NR 1.5.2 Multiple voices - part combining (issue4188056)
http://codereview.appspot.com/4188056/diff/1/Documentation/notation/simultaneous.itely File Documentation/notation/simultaneous.itely (right): http://codereview.appspot.com/4188056/diff/1/Documentation/notation/simultaneous.itely#newcode846 Documentation/notation/simultaneous.itely:846: change the state permanently. On 2011/02/16 03:50:29, Graham Percival wrote: Hmm. 5 commas in 4 sentences. You don't know German, do you? Here it's totally common to have 5 commas in one sentence! http://codereview.appspot.com/4188056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
