Re: Lyrics break estimation of vertical spacing

Boris Shingarov writes: > My work on Lilypond development has been temporarily put on the back > burner. Right now, we are concentrating on something slightly > different: we are working to secure a very large Lilypond-based > contract, for a major series of critical editions by a major publishe

Re: Simplification of live-elements-list, why not?

On 10-11-14 11:59 PM, Joe Neeman wrote: Any specific reason why not just filter on the is-live? predicate? Doesn't filter just work on plain scheme lists? elements is a grob-array object. Of course, if filter doesn't work on such objects it might be better to write a version of filter

oddHeaderMarkup and its kin are \paper variables?

These are essentially \paper variables, right? oddHeaderMarkup evenHeaderMarkup oddFooterMarkup evenFooterMarkup You have to set them in the \paper block, it seems, so I would like to categorize them alongside things like system-separator-markup. Would that make sense? So maybe this is s

Re: Simplification of live-elements-list, why not?

On Sun, Nov 14, 2010 at 5:19 PM, Boris Shingarov wrote: > In scm/output-lib.scm, the (internally used) function live-elements-listis > defined like this: > > (define (live-elements-list me) > (let* ((elements (ly:grob-object me 'elements)) >(elts-length (ly:grob-array-length eleme

Simplification of live-elements-list, why not?

In scm/output-lib.scm, the (internally used) function live-elements-list is defined like this: (define (live-elements-list me) (let* ((elements (ly:grob-object me 'elements)) (elts-length (ly:grob-array-length elements)) (live-elements '())) (let get-live ((len elts-

Re: Lyrics break estimation of vertical spacing

Please forgive me for bumping this discussion, but I was wondering if Valentin, I am sorry I have disappeared from the Lilypond scene for a while. My work on Lilypond development has been temporarily put on the back burner. Right now, we are concentrating on something slightly different: w

Re: Update spacing for Keith Ohara's suggested defaults (issue3099041)

Pushed to git. Thanks, Carl http://codereview.appspot.com/3099041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Fix 1382 (issue3100041)

On 2010/11/14 14:32:48, Valentin Villenave wrote: On Sun, Nov 14, 2010 at 3:17 PM, wrote: > I don't see how putting the names as variables helps anything.  The > whole string will need to be translated for localization, rather than > doing it one word at

Re: Fix 1382 (issue3100041)

On 2010/11/14 14:32:48, Valentin Villenave wrote: On Sun, Nov 14, 2010 at 3:17 PM, wrote: > I don't see how putting the names as variables helps anything.  The > whole string will need to be translated for localization, rather than > doing it one word at

Re: Doc: translations: manually update syntax (1358) (issue3092041)

On 2010/11/14 07:13:08, pacovila wrote: Graham: here are my comments. I will not close the issue until all other languages are revised, but for German it is done. Thanks I'll close this patch request, at least. http://codereview.appspot.com/3092041/diff/1/Documentation/de/notation/fretted-

Re: german doc patch, issue 1344

On Sun, Nov 14, 2010 at 08:25:22AM +0100, Francisco Vila wrote: > 2010/11/13 Graham Percival : > > There's been a simply German doc patch waiting for review for a few weeks: > > http://code.google.com/p/lilypond/issues/detail?id=1344 > > http://lists.gnu.org/archive/html/lilypond-devel/2010-09/msg0

Re: Universe of syntax possibilities, ONLY to skip over non-notes/chords

On 13/11/10 16:17, David Santamauro wrote: > I want to offer to do it, but I have some intense studying to do. Is > this the correct list to ask questions about this. I'm not in > inexperienced developer, just a novice with the internals of > lilypond. I just don't want to seem burdensome. > The ot

Re: Doc: NR 4.4.1: Clean up property descriptions. (issue3089042)

LGTM. Carl http://codereview.appspot.com/3089042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Docs: new spacing era

Le 14/11/2010 17:17, Mark Polesky disait : Jean-Charles Malahieude wrote: Do you mean that "It is the @code{default-staff-staff-spacing} property of each staff's @code{VerticalAxisGroup} grob that will be used when @code{staff-staff-spacing} is defined neither in @code{StaffGrouper} nor @code{V

Re: Doc: NR 4.4.1: Clean up property descriptions. (issue3089042)

Looks OK to me. Let's go. Trevor http://codereview.appspot.com/3089042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Doc: NR 4.4.1: Clean up property descriptions. (issue3089042)

Thanks, Trevor. Okay to push this now? - Mark http://codereview.appspot.com/3089042/diff/1/Documentation/notation/spacing.itely File Documentation/notation/spacing.itely (right): http://codereview.appspot.com/3089042/diff/1/Documentation/notation/spacing.itely#newcode1672 Documentation/notati

Re: Fix 1382 (issue3100041)

On Sun, Nov 14, 2010 at 3:17 PM, wrote: > I don't see how putting the names as variables helps anything.  The > whole string will need to be translated for localization, rather than > doing it one word at a time. What I meant is that if we ever decide to change the property names again, then it

Re: Fix 1382 (issue3100041)

On 2010/11/14 11:22:44, Valentin Villenave wrote: Hi Carl, looks good to me! I just have minor questions wrt coding style, but these are mainly because of my own ignorance :) http://codereview.appspot.com/3100041/diff/2001/input/regression/zero_staff_space.ly File input/regression/zero_s

Docs: new spacing era

Hi Mark, On my silent and long way to translate spacing.itely, I just got very confused by this paragraph (line 1730 - StaffGrouper's props): " @item staff-staff-spacing The distance between consecutive staves within the current staff-group. The @code{staff-staff-spacing} property of an indiv

Re: Doc: NR 4.4.1: Clean up property descriptions. (issue3089042)

On 2010/11/14 09:47:40, markpolesky_yahoo.com wrote: I don't follow -- "the use of the spacing suffix on property names..." Could you explain what you mean by that? My mistake! I think I must have misread staff-affinity. (I should have learned by now not to try to review things in 5 minutes

Re: Fix 1382 (issue3100041)

Hi Carl, looks good to me! I just have minor questions wrt coding style, but these are mainly because of my own ignorance :) http://codereview.appspot.com/3100041/diff/2001/input/regression/zero_staff_space.ly File input/regression/zero_staff_space.ly (right): http://codereview.appspot.com/310

Orpheus powered by LP

Unfortunately the server rejected my mail because I used the wrong adress: Nevertheless, here my yesterday's message: Tonight in Dresden (Germany) a premiere will take place: Gluck's "Orpheus and Euydike" (Vienna version) will be performed in a staging made by the former Forsythe-dancer Thomas

Re: Doc: NR 4.4.1: Clean up property descriptions. (issue3089042)

Trevor Daniels wrote: > Looks a lot better. I've indicated one detail. Also the > use of the spacing suffix on property names looks > inconsistent to me. I've not marked these as there may be > more outside this patch, but it seems to be omitted or > included fairly randomly. Could you check th

Re: Corrections and additions to NR 4.1.2, "Page formatting". (issue1710046)

On 2010/11/14 06:59:41, Mark Polesky wrote: On 2010/11/13 17:33:47, Graham Percival wrote: > This patch cannot be applied to current master. [...] I don't want to be a spoilsport, but I have a patch of my own that I'm pretty sure takes care of everything involved here (and more): http://codere

Re: Doc: NR 4.4.1: Clean up property descriptions. (issue3089042)

Looks a lot better. I've indicated one detail. Also the use of the spacing suffix on property names looks inconsistent to me. I've not marked these as there may be more outside this patch, but it seems to be omitted or included fairly randomly. Could you check this out? Trevor http://codere

Re: Add tab-tie-follow-engraver (issue2723043)

Carl Sorensen writes: > On 11/13/10 3:23 AM, "David Kastrup" wrote: > >> Carl Sorensen writes: >> >>> On 11/13/10 2:01 AM, "David Kastrup" wrote: >>> carl.d.soren...@gmail.com writes: > >>> You sort the noteheads according to some criterion, and use the same criterion f