texinfo_document.po files encoding

[Federico Bruni]

I've received the texinfo_document.po file from the Translation Project.
While looking at other languages po files to understand what to 
translate and what to leave untraslated, I've noticed some strange 
characters. Probably because these files are saved as ASCII instead of 
UTF-8?



$ file texinfo_document-5.0.fr.po
texinfo_document-5.0.fr.po: GNU gettext message catalogue, ASCII text

For example: Forme Sp@'eciale

http://translationproject.org/domain/texinfo_document.html

--
Federico

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Make test-output-distance regtest contain span bars (issue 7400057)

[dak]

Reviewers: lemzwerg, thomasmorley65,

Message:
On 2013/02/28 00:45:57, thomasmorley65 wrote:

LGTM



One suggestion:



https://codereview.appspot.com/7400057/diff/1/input/regression/test-output-distance.ly

File input/regression/test-output-distance.ly (right):



https://codereview.appspot.com/7400057/diff/1/input/regression/test-output-distance.ly#newcode20

input/regression/test-output-distance.ly:20:
How about setting \bar "|."
Might be a stronger flag.


I think we have a special span bar at the start, and a default span bar
at the end.  \bar "|." would leave us only with special span bars unless
one expands the whole example by another bar.  Neither option makes me
really enthused, but I am willing to let myself be convinced.

Description:
Make test-output-distance regtest contain span bars

Since span bars don't turn up in the metrics, the regtests don't show
them.  To make catastrophic span bar failures show up at least
somewhere, the ever-changing test-output-distance test is made to
include them.

Please review this at https://codereview.appspot.com/7400057/

Affected files:
  M input/regression/test-output-distance.ly


Index: input/regression/test-output-distance.ly
diff --git a/input/regression/test-output-distance.ly  
b/input/regression/test-output-distance.ly
index  
6ea91213b7c606996dad291486c713fb3eefd0d7..ef10b57f9c629175c4c93db2c5ce05b14dc6924a  
100644

--- a/input/regression/test-output-distance.ly
+++ b/input/regression/test-output-distance.ly
@@ -18,5 +18,7 @@ it should always show up in the output-distance testing. "
   ragged-right = ##f
 }

-\relative c' { c4 d f8_\f[ g-.] }
+\new PianoStaff << \new Staff \relative c' { c4 d f8_\f[ g-.] r4 }
+  \new Staff { \clef "bass" R1 }
+   >>




___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Uses only unpure-pure containers to articulate unpure-pure relationships. (issue 7377046)

[dak]

On 2013/02/27 23:00:48, mike7 wrote:

On 27 févr. 2013, at 19:06, mailto:d...@gnu.org wrote:



>
>


https://codereview.appspot.com/7377046/diff/17001/input/regression/scheme-text-spanner.ly

> File input/regression/scheme-text-spanner.ly (right):
>
>


https://codereview.appspot.com/7377046/diff/17001/input/regression/scheme-text-spanner.ly#newcode129

> input/regression/scheme-text-spanner.ly:129:
> side-position-interface::y-aligned-side)
> I really don't understand why you ask on the developer list about
> gratuitous prefix changes because of a different implementation

language

> when you propose such changes right afterwards.
>



In my e-mail, I stated:
"I'd prefer if all native Scheme functions did not have the ly: prefix

- it

helps to know what things are where."


So why do you ask when you ignore the answer?


side-position-interface::y-aligned-side above is a native Scheme

function that

does not have the ly: prefix.


You remove the prefix in this patch set.


> https://codereview.appspot.com/7377046/diff/17001/lily/grob.cc
> File lily/grob.cc (right):
>
>

https://codereview.appspot.com/7377046/diff/17001/lily/grob.cc#newcode866

> lily/grob.cc:866: if (to_boolean (scm_object_property
> (me->get_property_data ("stencil"), ly_symbol2scm ("ly:stencil?"
> Where is this object property being set?



In define-grobs.scm.


I've looked very thoroughly without success.  I can't find a setting
of the ly:stencil? object property in your patch set, and I can't find
it in the current code base, either.

Care for a line number?


https://codereview.appspot.com/7377046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Single Whole Measure Rest vs compressed MMR

[Werner LEMBERG]

> 1. Are "single Whole Measure Rest" and "compressed MMR" two different
> things, and treated as such, with specific rules, etc. in references
> like Ross, Read, Gould?

As far as I know, they are treated similarly.  Why should there be a
difference?  The idea of having compressed MMRs is to save horizontal
space, isn't it?

Can you show us some literature scans which supports your claim?


Werner

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Make test-output-distance regtest contain span bars (issue 7400057)

[thomasmorley65]

LGTM

One suggestion:


https://codereview.appspot.com/7400057/diff/1/input/regression/test-output-distance.ly
File input/regression/test-output-distance.ly (right):

https://codereview.appspot.com/7400057/diff/1/input/regression/test-output-distance.ly#newcode20
input/regression/test-output-distance.ly:20:
How about setting \bar "|."
Might be a stronger flag.

https://codereview.appspot.com/7400057/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Single Whole Measure Rest vs compressed MMR (WAS: Issue 3208 Wrong MultiMeasureRest glyph)

[Thomas Morley]

2013/2/28 Xavier Scheuer :

> I sometimes wanted different horizontal space settings for "single Whole
> Measure Rest" and "real" multimeasure rests a.k.a "compressed MMR"
> (with a number above).

Hi again.

BTW, you could print the MultiMeasureRestNumber on a "single Whole
Measure Rest", too:

{ \set restNumberThreshold = #0 R1 }


-Harm

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Single Whole Measure Rest vs compressed MMR (WAS: Issue 3208 Wrong MultiMeasureRest glyph)

[Thomas Morley]

2013/2/28 Xavier Scheuer :
> On 27 February 2013 18:13,   wrote:
>>
>> Comment #1 on issue 3208 by philehol...@googlemail.com: Wrong
>> MultiMeasureRest glyph
>> http://code.google.com/p/lilypond/issues/detail?id=3208
>>
>> OK - let's just be clear about what the bug is.  Lilypond does the right
>> thing (TM) for single Whole Measure Rests - breve rests and longa rests are
>> correct.  It does the wrong thing for multimeasure rests, where what it uses
>> for 2 breve bar rests (staff system 2 above) it uses the symbol for a 4 bar
>> church rest.  That's wrong, agreed, and needs fixing.
>
> This reminds me of a question/issue I never asked here.
>
> I sometimes wanted different horizontal space settings for "single Whole
> Measure Rest" and "real" multimeasure rests a.k.a "compressed MMR"
> (with a number above).

Hi Xavier,

do you think of sth like this:

\version "2.17.12"

boundPadding =
\override MultiMeasureRest #'before-line-breaking =
  #(lambda (grob)
(let* ((measure-count (ly:grob-property grob 'measure-count))
   (b-p (if (> measure-count 1)
  20;; bound-padding for single MMR
  15))) ;; bound-padding for compressed MMR
   (ly:grob-set-property! grob 'bound-padding b-p)))

{
\boundPadding
R1
\repeat unfold 20 { c'' }
}

{
\boundPadding
\compressFullBarRests
R1*5
\repeat unfold 20 { c'' }
}

Cheers,
  Harm

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Single Whole Measure Rest vs compressed MMR (WAS: Issue 3208 Wrong MultiMeasureRest glyph)

[Xavier Scheuer]

On 27 February 2013 18:13,   wrote:
>
> Comment #1 on issue 3208 by philehol...@googlemail.com: Wrong
> MultiMeasureRest glyph
> http://code.google.com/p/lilypond/issues/detail?id=3208
>
> OK - let's just be clear about what the bug is.  Lilypond does the right
> thing (TM) for single Whole Measure Rests - breve rests and longa rests are
> correct.  It does the wrong thing for multimeasure rests, where what it uses
> for 2 breve bar rests (staff system 2 above) it uses the symbol for a 4 bar
> church rest.  That's wrong, agreed, and needs fixing.

This reminds me of a question/issue I never asked here.

I sometimes wanted different horizontal space settings for "single Whole
Measure Rest" and "real" multimeasure rests a.k.a "compressed MMR"
(with a number above).

Currently LilyPond does not consider "single Whole Measure Rest" and
"compressed MMR" differently.

1. Are "single Whole Measure Rest" and "compressed MMR" two different
things, and treated as such, with specific rules, etc. in references
like Ross, Read, Gould?

2. Would it make sense to have different grobs to handle these two
with different properties settings ?

Thank you for your attention.

Cheers,
Xavier

-- 
Xavier Scheuer 

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Uses only unpure-pure containers to articulate unpure-pure relationships. (issue 7377046)

[m...@mikesolomon.org]

On 27 févr. 2013, at 19:06, d...@gnu.org wrote:

> 
> https://codereview.appspot.com/7377046/diff/17001/input/regression/scheme-text-spanner.ly
> File input/regression/scheme-text-spanner.ly (right):
> 
> https://codereview.appspot.com/7377046/diff/17001/input/regression/scheme-text-spanner.ly#newcode129
> input/regression/scheme-text-spanner.ly:129:
> side-position-interface::y-aligned-side)
> I really don't understand why you ask on the developer list about
> gratuitous prefix changes because of a different implementation language
> when you propose such changes right afterwards.
> 

In my e-mail, I stated:
"I'd prefer if all native Scheme functions did not have the ly: prefix - it 
helps to know what things are where."
side-position-interface::y-aligned-side above is a native Scheme function that 
does not have the ly: prefix.

> https://codereview.appspot.com/7377046/diff/17001/lily/axis-group-interface.cc
> File lily/axis-group-interface.cc (right):
> 
> https://codereview.appspot.com/7377046/diff/17001/lily/axis-group-interface.cc#newcode261
> lily/axis-group-interface.cc:261: if (!g->is_live ())
> Shouldn't you check for liveness before anything else?

The call to check the cross-staff property above could trigger the suicide.
In general, it is better to access properties first, suicide later.

> 
> https://codereview.appspot.com/7377046/diff/17001/lily/grob-property.cc
> File lily/grob-property.cc (right):
> 
> https://codereview.appspot.com/7377046/diff/17001/lily/grob-property.cc#newcode345
> lily/grob-property.cc:345: if (is_simple_closure (unpure))
> This is not related to this patch and review, but can anybody explain
> why this simple_closure $#!+ can't be replaced by a callable closure
> created using a smob type made callable via scm_set_smob_apply?  Is it
> because of the delayed arg?  Can't we deal with that by using a fluid
> (in Scheme, a parameter) in evaluate_with_simple_closure?  These pseudo
> "simple" closures really make my head ache, and being able to throw all
> of them out would be quite a boon.

Agreed.

> 
> https://codereview.appspot.com/7377046/diff/17001/lily/grob-scheme.cc
> File lily/grob-scheme.cc (right):
> 
> https://codereview.appspot.com/7377046/diff/17001/lily/grob-scheme.cc#newcode454
> lily/grob-scheme.cc:454: SCM_ASSERT_TYPE (ly_is_procedure (proc) ||
> is_unpure_pure_container (proc), proc, SCM_ARG2, __FUNCTION__,
> "procedure or unpure pure container");
> Possibly worth a named type predicate of its own?

Possibly.  Could be in a separate patch.

> 
> https://codereview.appspot.com/7377046/diff/17001/lily/grob.cc
> File lily/grob.cc (right):
> 
> https://codereview.appspot.com/7377046/diff/17001/lily/grob.cc#newcode866
> lily/grob.cc:866: if (to_boolean (scm_object_property
> (me->get_property_data ("stencil"), ly_symbol2scm ("ly:stencil?"
> Where is this object property being set?

In define-grobs.scm.

> 
> https://codereview.appspot.com/7377046/diff/17001/scm/output-lib.scm
> File scm/output-lib.scm (right):
> 
> https://codereview.appspot.com/7377046/diff/17001/scm/output-lib.scm#newcode61
> scm/output-lib.scm:61: (define-public
> (grob::wrap-in-unpure-pure-container fn)
> After issue 3200 passed, this is just ly:make-unpure-pure-container.
> Remove, change all its callers.

Ok. I'll try to remember for this patch set.

> 
> https://codereview.appspot.com/7377046/diff/17001/scm/output-lib.scm#newcode89
> scm/output-lib.scm:89: (define-public
> grob::always-vertical-skylines-from-stencil
> I don't think that these are worth a definition of their own.  Better
> expand them inline.  An unpure-pure container is cheap enough that
> having separate containers for each use is not really a problem.
> 

They reappear several times.  It is a useful heuristic so that if I need to 
change how this works, I only need to change it in one place instead of several.

Thanks for the review!

Cheers,
MS


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Make test-output-distance regtest contain span bars (issue 7400057)

[lemzwerg]

LGTM.

https://codereview.appspot.com/7400057/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Uses only unpure-pure containers to articulate unpure-pure relationships. (issue 7377046)

[dak]

https://codereview.appspot.com/7377046/diff/17001/input/regression/scheme-text-spanner.ly
File input/regression/scheme-text-spanner.ly (right):

https://codereview.appspot.com/7377046/diff/17001/input/regression/scheme-text-spanner.ly#newcode129
input/regression/scheme-text-spanner.ly:129:
side-position-interface::y-aligned-side)
I really don't understand why you ask on the developer list about
gratuitous prefix changes because of a different implementation language
when you propose such changes right afterwards.

https://codereview.appspot.com/7377046/diff/17001/lily/axis-group-interface.cc
File lily/axis-group-interface.cc (right):

https://codereview.appspot.com/7377046/diff/17001/lily/axis-group-interface.cc#newcode261
lily/axis-group-interface.cc:261: if (!g->is_live ())
Shouldn't you check for liveness before anything else?

https://codereview.appspot.com/7377046/diff/17001/lily/grob-property.cc
File lily/grob-property.cc (right):

https://codereview.appspot.com/7377046/diff/17001/lily/grob-property.cc#newcode345
lily/grob-property.cc:345: if (is_simple_closure (unpure))
This is not related to this patch and review, but can anybody explain
why this simple_closure $#!+ can't be replaced by a callable closure
created using a smob type made callable via scm_set_smob_apply?  Is it
because of the delayed arg?  Can't we deal with that by using a fluid
(in Scheme, a parameter) in evaluate_with_simple_closure?  These pseudo
"simple" closures really make my head ache, and being able to throw all
of them out would be quite a boon.

https://codereview.appspot.com/7377046/diff/17001/lily/grob-scheme.cc
File lily/grob-scheme.cc (right):

https://codereview.appspot.com/7377046/diff/17001/lily/grob-scheme.cc#newcode454
lily/grob-scheme.cc:454: SCM_ASSERT_TYPE (ly_is_procedure (proc) ||
is_unpure_pure_container (proc), proc, SCM_ARG2, __FUNCTION__,
"procedure or unpure pure container");
Possibly worth a named type predicate of its own?

https://codereview.appspot.com/7377046/diff/17001/lily/grob.cc
File lily/grob.cc (right):

https://codereview.appspot.com/7377046/diff/17001/lily/grob.cc#newcode866
lily/grob.cc:866: if (to_boolean (scm_object_property
(me->get_property_data ("stencil"), ly_symbol2scm ("ly:stencil?"
Where is this object property being set?

https://codereview.appspot.com/7377046/diff/17001/scm/output-lib.scm
File scm/output-lib.scm (right):

https://codereview.appspot.com/7377046/diff/17001/scm/output-lib.scm#newcode61
scm/output-lib.scm:61: (define-public
(grob::wrap-in-unpure-pure-container fn)
After issue 3200 passed, this is just ly:make-unpure-pure-container.
Remove, change all its callers.

https://codereview.appspot.com/7377046/diff/17001/scm/output-lib.scm#newcode89
scm/output-lib.scm:89: (define-public
grob::always-vertical-skylines-from-stencil
I don't think that these are worth a definition of their own.  Better
expand them inline.  An unpure-pure container is cheap enough that
having separate containers for each use is not really a problem.

https://codereview.appspot.com/7377046/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

PATCHES: Countdown to Sat 2nd March 07:00 GMT

[James]

 *Countdown – March 2nd 2013 – 07:00 GMT* *
* *
* *
* *
* *
*











 
3201
Enhancement David Kastrup Push Patch: Don't initialize dim_cache_ array via
constructor syntax
 
3169
Enhancement Mike Solomon Push Patch: Fixes annotate spacing
 
2985
Defect David Kastrup Push lilypond: Umlauts and other special characters
incorrectly exported to PDF meta data   Backport






 
3202
Enhancement David Kastrup countdown Patch: changes.tely: deal with
\transposition and instrumentTransposition changes
 
3206
Documentation Aleksandr Andreev countdown Patch: Document Kievan ligature
engraver
 
3203
Critical David Kastrup countdown Connecting bar lines missing in piano
staffs   Regression












 
3211
Defect
David Kastrup review Patch: Let ly_deep_copy and ly_music_deep_copy iterate
rather than recurse for lists
3205
Crash
David Kastrup review opening bar check causes crash if \score contains the
\midi block
3199
Enhancement
Mike Solomon review Patch: Uses only unpure-pure containers to articulate
unpure-pure relationships.
3161
Enhancement
Mike Solomon review Patch: Standardizes use of empty extents in pure
heights and skylines.
3160
Defect
Mike Solomon review chord names pushed into the staff   Regression
3134
Enhancement
Mike Solomon review Patch: Removes the translate_axis call from
axis-group-interface outside-staff positioning.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Change in lilypond-book

[Phil Holmes]

- Original Message - 
From: "Trevor Daniels" 

To: ; "David Kastrup" 
Sent: Tuesday, February 26, 2013 6:45 PM
Subject: Re: Change in lilypond-book




David  and Phil wrote:


From: "Trevor Daniels" 


I've just run lilypond-book on Windows Vista after several months of
inactivity and I find its behaviour has changed.

Before I try to narrow down where this change originated, is this
now intended?  Surely not.  Expected?  Do others see this behaviour?


It's a bug in 2.17.12.  Upgrade to 2.17.13.


Except that 2.17.13 has this pesky spanbar bug.


Thanks, both.  I can live with it for a couple of weeks.  I need the
spanbars.

Trevor



If it gets on your nerves, you could downgrade to 2.17.11.

--
Phil Holmes

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Document Kievan ligature engraver (issue 7382060)

[aleksandr . andreev]

On 2013/02/27 09:24:07, Trevor Daniels wrote:

On 2013/02/27 03:26:11, aleksandr.andreev wrote:
> Looking at the sections on Mensural and Gregorian notations, it

looks like the

> \transpose c c' syntax is used quite often there. On the other hand,

the

> \relative syntax is used in the "scenarios and solutions" section. I

don't

mind
> changing this example (as well as the example at the beginning of

the Kievan

> section), but perhaps we should then make all of the examples in the

Ancient

> notation chapter consistent?



I think changing all the examples to \relative would be good, but I'm

happy to

leave this to a separate patch if you prefer.  The Ancient section was

not

included in the push for consistency some years ago due to lack of
interest/effort.  But better late than never.



Trevor


I think it makes sense to push this patch first and then I will upload
another patch that changes the syntax across the manual. That way it is
cleaner in the commit history.

There is also Issue 1287. I could try to work on improving the ancient
notation chapter, though I am no expert in Gregorian chant.

https://codereview.appspot.com/7382060/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Musings on interfaces and properties

[David Kastrup]

"m...@mikesolomon.org"  writes:

> Working on eliminating the translate_axis call from
> axis-group-interface, I've found a less-than-ideal situation in the
> naming/using of interfaces and properties that I'd like to clean up,
> but it'd be a major, major change and would take time to implement.
> So, before starting it as a project, I want to know if people think it
> is a good idea.
>
> Currently, interfaces can have whatever properties they want, leading
> things like `padding' or `staff-padding' to mean different things in
> different interfaces (tuplet-bracket-interface and
> side-position-interface, for example).  This is bad when you try to
> mix functions from the two interfaces together that think these
> properties mean different things.

Why would one want to mix?  Do we have grobs using both interfaces?

> To avoid this, there are a few steps we could take:
>
> 1) Require that, for a grob to use a callback from an interface, it
> must implement that interface.

I doubt that we should actually require that, but it's probably "all
bet's are off" terrain when one does differently.

> 2) Require that, for a callback to lookup a property, the property
> must be implemented by the interface that the callback is part of
> (i.e. ly:side-position-interface::y-aligned-side can only look up
> properties from side-position-interface).

Hm.

> 3) Have interface multiple inheritance so that, for example, all
> properties of grob-interface are accessible by
> side-position-interface.

We definitely should not think about "multiple inheritance" in the
current state of the code base.

> 4) In cases where a grob implements multiple interfaces that have the
> same property, the property must be specified as property@interface
> (padding@side-position-interface).  Otherwise, LilyPond issues a
> warning and sets all paddings to the value for all pertinent
> interfaces.
> 5) In define-grob-properties.scm, specify all interfaces for properties.
>
> What do people think?

I think that at the current point of time, we should try getting along
with a flat namespace approach.  That might imply renaming properties
like "padding" to "side-padding" if we can't achieve reasonable results
otherwise.  Not sure about that.

Callbacks at the current point of time receive a "grob" as argument.  I
don't think that this "grob" should be converted to some subgrob pared
down to what the interface is "allowed" to see as it makes handling grob
identity a mess.

Point 1) makes some sense as a stipulation.  Trying to enforce this
stipulation, however, gets into variants of 2-5.  I don't think we
should at the current point of time go there.  The whole deal of context
and grob properties is too entangled to try cleaning them up separately.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Includes empty skylines in minimum translation calculations (issue 7304068)

[m...@mikesolomon.org]

On 27 févr. 2013, at 07:06, k-ohara5...@oco.net wrote:

> Also needs some decruftification.
> 
> 
> https://codereview.appspot.com/7304068/diff/22001/lily/align-interface.cc
> File lily/align-interface.cc (right):
> 
> https://codereview.appspot.com/7304068/diff/22001/lily/align-interface.cc#newcode299
> lily/align-interface.cc:299: vector non_empty_elems;
> The disassembly and reassembly of the array is ridiculous, but with the
> comment at least people will not be confused, merely laugh.
> 
> https://codereview.appspot.com/7304068/diff/22001/scm/define-grobs.scm
> File scm/define-grobs.scm (right):
> 
> https://codereview.appspot.com/7304068/diff/22001/scm/define-grobs.scm#newcode2031
> scm/define-grobs.scm:2031: (horizon-padding . 100)
> You don't need this anymore, and it will terribly confuse some poor
> songwriter somewhere, if left in.

Removed.

Thanks for the review!

Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Standardizes use of empty extents in pure heights and skylines. (issue 7310075)

[m...@mikesolomon.org]

On 27 févr. 2013, at 07:03, k-ohara5...@oco.net wrote:

> Just needs cleanup of some leftover unneeded complications.
> 
> 
> https://codereview.appspot.com/7310075/diff/38001/lily/skyline.cc
> File lily/skyline.cc (right):
> 
> https://codereview.appspot.com/7310075/diff/38001/lily/skyline.cc#newcode488
> lily/skyline.cc:488: will be ignored.
> What do you mean by "they will be ignored"?  On line 501, empty segments
> seem to be reversed, making non-empty segments.
> 

Fixed. Bad copy and paste.

> https://codereview.appspot.com/7310075/diff/38001/ly/engraver-init.ly
> File ly/engraver-init.ly (right):
> 
> https://codereview.appspot.com/7310075/diff/38001/ly/engraver-init.ly#newcode896
> ly/engraver-init.ly:896: \override Clef.Y-extent =
> #grob::all-heights-from-stencil
> Why the \overrride to the same value as its default ?

Fixed.

> 
> https://codereview.appspot.com/7310075/diff/38001/ly/gregorian.ly
> File ly/gregorian.ly (right):
> 
> https://codereview.appspot.com/7310075/diff/38001/ly/gregorian.ly#newcode103
> ly/gregorian.ly:103: \once \override BreathingSign.Y-extent =
> #grob::all-heights-from-stencil
> This is now the default, so no need for overrides.

Fixed.

> 
> https://codereview.appspot.com/7310075/diff/38001/scm/define-grobs.scm
> File scm/define-grobs.scm (right):
> 
> https://codereview.appspot.com/7310075/diff/38001/scm/define-grobs.scm#newcode1825
> scm/define-grobs.scm:1825: (Y-extent .
> ,grob::unpure-empty-pure-point-height)
>   (Y-extent . ,grob::all-heights-from-stencil)
> 
> We do not /want/ to allow outside-staff objects to slide down alongside
> note-heads protruding from the staff, if by doing so they overlap any
> repeat ties that might be there.

I'll take this for a spin...not sure if it'll work but no harm regtesting it.  
My goal was to preserve the original behavior, but if this is better no harm in 
using it. 

> 
> https://codereview.appspot.com/7310075/diff/38001/scm/define-grobs.scm#newcode1992
> scm/define-grobs.scm:1992: ; should preserve the span bar's presence for
> horizontal spacing
> "want this to be ignored" when ?
> Presumably during staff-spacing, but what problem could it cause if not
> ignored ?
> 

It will be part of the skyline, potentially blocking things that shouldn't be 
blocked.

> If staves would otherwise move away trying to make room for it, the
> SpanBar avoids this using cross-staff = ##t

The SpanBar has no height, so it is never taken into account in spacing.

> 
> https://codereview.appspot.com/7310075/diff/38001/scm/define-grobs.scm#newcode1993
> scm/define-grobs.scm:1993: (Y-extent .
> ,grob::unpure-empty-pure-point-height)
> (Y-extent . (0 . 0))
> 

See above.

> https://codereview.appspot.com/7310075/diff/38001/scm/lily-library.scm
> File scm/lily-library.scm (right):
> 
> https://codereview.appspot.com/7310075/diff/38001/scm/lily-library.scm#newcode629
> scm/lily-library.scm:629: (define-public small-empty-interval '(0.01 .
> -0.01))
> orphaned
> 

Abandoned.

> https://codereview.appspot.com/7310075/diff/38001/scm/output-lib.scm
> File scm/output-lib.scm (right):
> 
> https://codereview.appspot.com/7310075/diff/38001/scm/output-lib.scm#newcode69
> scm/output-lib.scm:69: (ly:make-unpure-pure-container #f '(0 . 0)))
> The changes to define-grobs.scm work for me, so this can be orphaned,
> thankfully.

I'm with you on RepeatTie, but not SpanBarStub.  SpanBarStub needs to only have 
height in Separation_item::boxes which is accomplished via the addition of 
extra-spacing-height.  Otherwise we don't want the spacing engine to know it's 
there.  This can be accomplished (for now) by having a point pure height and 
adding the extra-spacing-height.  The problem is that the notion "horizontal 
spacing equals pure height plus extra spacing height" is hardcoded into 
Separation_item::boxes.  There should be horizontal-spacing-height and 
horizontal-spacing-width instead of extra-spacing-height and 
extra-spacing-width that has set as a default pure-height and width unless 
specified otherwise.

But changing that would be a UI nightmare, so I'm reluctant to do it.

Cheers,
MS___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Uses only unpure-pure containers to articulate unpure-pure relationships. (issue 7377046)

[m...@mikesolomon.org]

On 27 févr. 2013, at 07:22, k-ohara5...@oco.net wrote:

> The cardinal cantle seems meldable, but first the cruft needs to be
> strained.
> 
> 
> https://codereview.appspot.com/7377046/diff/11001/scm/define-grobs.scm
> File scm/define-grobs.scm (right):
> 
> https://codereview.appspot.com/7377046/diff/11001/scm/define-grobs.scm#newcode1827
> scm/define-grobs.scm:1827: (Y-extent .
> ,grob::unpure-empty-pure-point-height)
>  (Y-extent . ,grob::always-Y-extent-from-stencil)

Are you sure we want this?  This isn't what was there previously.  Previously, 
there was no height for these grobs save '(0 . 0) as a pure height.

> 
> This leaked in from another patch set.
> 
> https://codereview.appspot.com/7377046/diff/11001/scm/output-lib.scm
> File scm/output-lib.scm (right):
> 
> https://codereview.appspot.com/7377046/diff/11001/scm/output-lib.scm#newcode108
> scm/output-lib.scm:108: ;; decisions, so we make their unpure height #f.
> This gives a way for an object to say: "Please leave space for me as if
> I were just a dot, while I am still a virgin (before page-breaking) but
> once I have carnal knowledge (during final page-layout) feel free to
> print other things right on top of me."
> Eeew.
> 

As a developer whose work is pure as snow, I can't even fathom what you mean.  
My brain is going into catatonic mode to protect my innocence.

Cheers,
MS


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Musings on interfaces and properties

[m...@mikesolomon.org]

Hey all,

Working on eliminating the translate_axis call from axis-group-interface, I've 
found a less-than-ideal situation in the naming/using of interfaces and 
properties that I'd like to clean up, but it'd be a major, major change and 
would take time to implement.  So, before starting it as a project, I want to 
know if people think it is a good idea.

Currently, interfaces can have whatever properties they want, leading things 
like `padding' or `staff-padding' to mean different things in different 
interfaces (tuplet-bracket-interface and side-position-interface, for example). 
 This is bad when you try to mix functions from the two interfaces together 
that think these properties mean different things.

To avoid this, there are a few steps we could take:

1) Require that, for a grob to use a callback from an interface, it must 
implement that interface.
2) Require that, for a callback to lookup a property, the property must be 
implemented by the interface that the callback is part of (i.e. 
ly:side-position-interface::y-aligned-side can only look up properties from 
side-position-interface).
3) Have interface multiple inheritance so that, for example, all properties of 
grob-interface are accessible by side-position-interface.
4) In cases where a grob implements multiple interfaces that have the same 
property, the property must be specified as property@interface 
(padding@side-position-interface).  Otherwise, LilyPond issues a warning and 
sets all paddings to the value for all pertinent interfaces.
5) In define-grob-properties.scm, specify all interfaces for properties.

What do people think?

Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Document Kievan ligature engraver (issue 7382060)

[tdanielsmusic]

On 2013/02/27 03:26:11, aleksandr.andreev wrote:

Looking at the sections on Mensural and Gregorian notations, it looks

like the

\transpose c c' syntax is used quite often there. On the other hand,

the

\relative syntax is used in the "scenarios and solutions" section. I

don't mind

changing this example (as well as the example at the beginning of the

Kievan

section), but perhaps we should then make all of the examples in the

Ancient

notation chapter consistent?


I think changing all the examples to \relative would be good, but I'm
happy to leave this to a separate patch if you prefer.  The Ancient
section was not included in the push for consistency some years ago due
to lack of interest/effort.  But better late than never.

Trevor




https://codereview.appspot.com/7382060/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: changes.tely: deal with \transposition and instrumentTransposition changes (issue 7404046)

[dak]

On 2013/02/27 07:40:59, Keith wrote:

On 2013/02/27 05:58:58, Keith wrote:



> (and @code{\whateverItWasCalled f'} is available



Oops.  It was \oldTransposition  but it was not put into LilyPond.


Since the sign of instrumentTransposition has been inverted, it would
require serious trickery or a separate music event type to implement
\oldTransposition with the previous semantics.  Getting the previous
semantics for instrument definitions seems even worse.


On the one hand, any score that used \transposition p  in music that

goes

through transpose will change its behavior.


Yes.  I think the most likely candidates would be
\transpose c' bes { \transposition c' ...
where "\transposition c'" is used in the meaning "I don't care what you
do with \transpose, the following is concert pitch".

It might make some sense to complain about this special case and/or the
pattern
\transpose [letters, spaces, octaves]*{[space]\transposition
in convert-ly rules.


On the other hand, I /think/ that the only cases where the old

behavior was

useful would have one \transposition at the start of the section of

music, so

transforming to the new LilyPond is simple---rather, relatively simple

in the

world of writing for transposing instruments.



Back to the first hand, search/replace to use \oldTransposition  is

easier to

explain to the impatient, than how to write for transposing

instruments.

The problem I have with supporting \oldTransposition behavior in the
standard code is that we won't ever get rid it again.  We still have an
"old-relative" option to revert to LilyPond 1.8 behavior for \relative,
and the associated code paths.  Probably nobody has a clue what this
actually does, or whether it actually still does what it was intended to
do once.

https://codereview.appspot.com/7404046/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issue 3205: opening bar check causes crash if \score contains the \midi block (issue 7377057)

[dak]

Reviewers: Keith,

Message:
On 2013/02/27 07:07:58, Keith wrote:

I tried skipTypesetting and showFirstLength in different situations.

They seem

to work.



It would be nice to know at least /how/ this change causes
Score_performer::prepare() to be called.



On the other hand, it seems that the bar-check-iterator should not

have caused

Score_performer::one_time_step() to be called at all.


It is not the bar-check-iterator that calls one_time_step as you can see
by leaving off the note.  But the bar-check-iterator causes
Score_performer::prepare to be missed.

The code in score-performer.cc (as well as score-engraver.cc except that
the latter does not mind missing prepare all that much) registers
listeners for Prepare and OneTimeStep _when_ the Score context is
created.

A mere \context Score { | d } is already enough to prevent the segfault.
 But if you start right with | without a score context, Prepare and
OneTimeStep only get registered once d turns up, and it would appear
that the Prepare event has gone by that time and is no longer seen by
the listener.

I have no clue what makes the standard Music_iterator different here.
The only other use of Simple_music_iterator is with \partial, and
\partial wraps its music event in (descend-to-context ... and thus is
impervious to this problem (the raw music event in itself will likely
crash LilyPond equally well).

I have no idea what Simple_music_iterator is for.  Possibly for getting
triggered at most once per time step, but then it should likely be
possible to get this effect without needing to actually compare moments.

Description:
Issue 3205: opening bar check causes crash if \score contains the \midi
block

This derives Bar_check_iterator from Music_iterator rather than from
Simple_music_iterator.

In
\score {
  { | d }
  \midi { }
}

the bar check iterator is being called while only the \Global context
exists.  That causes Score_performer::one_time_step to be called
without getting Score_performer::prepare to be called previously,
probably because the Score context is created at the wrong time.  The
Score_performer is not prepared for this situation.

I have no idea how to fix Simple_music_iterator, why it exists in the
first place and is written like it is, and why this appears to work.

Please review this at https://codereview.appspot.com/7377057/

Affected files:
  M lily/bar-check-iterator.cc


Index: lily/bar-check-iterator.cc
diff --git a/lily/bar-check-iterator.cc b/lily/bar-check-iterator.cc
index  
a0fb8eaee17391231734a889ce2ec7e480615c98..ea4794897d3353f9fddae5c607ffe1f33fd78898  
100644

--- a/lily/bar-check-iterator.cc
+++ b/lily/bar-check-iterator.cc
@@ -27,7 +27,7 @@
   Check bar checks. We do this outside the engravers so that you can
   race through the score using skipTypesetting to correct durations.
 */
-class Bar_check_iterator : Simple_music_iterator
+class Bar_check_iterator : Music_iterator
 {
 public:
   virtual void process (Moment);
@@ -44,7 +44,7 @@ Bar_check_iterator::Bar_check_iterator ()
 void
 Bar_check_iterator::process (Moment m)
 {
-  Simple_music_iterator::process (m);
+  Music_iterator::process (m);
   if (!m.to_bool ())
 {
   Context *tr = get_outlet ();



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel