Re: Don't let dots go negative in scaleDurations -- Fix Issue 2048 (issue 5437059)

[pkx166h]

passes make one reg test shows up

http://code.google.com/p/lilypond/issues/detail?id=2048#c5

James

http://codereview.appspot.com/5437059/

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

Re: Better pure heights for slurs (issue 5431065)

[pkx166h]

passes make - reg test diffs attached here:

http://code.google.com/p/lilypond/issues/detail?id=2051#c4

James

http://codereview.appspot.com/5431065/

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

Re: OT: Vocal music

[Werner LEMBERG]

> I'm working on a book of madrigals right now and some of it is
> recorded.  The YouTube excerpt has affinities w/ mm. 21-30 of the
> attached PDF & audio file (it's an excerpt from the 3rd madrigal in
> the book, called "Lucky Wok (star!)").

Your sample sounds really amazing!  However, the notation is extremely
complicated: I've listened five times to it, but I still wasn't able
to follow the score...  Any chance to make it more simple?  Obviously,
you know far too much about lilypond to produce such well looking
scores :-)


Werner

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

Re: OT: Vocal music

[mike]

On Fri, 25 Nov 2011 10:52:26 +0100 (CET), Werner LEMBERG wrote:

I'm working on a book of madrigals right now and some of it is
recorded.  The YouTube excerpt has affinities w/ mm. 21-30 of the
attached PDF & audio file (it's an excerpt from the 3rd madrigal in
the book, called "Lucky Wok (star!)").


Your sample sounds really amazing!  However, the notation is 
extremely

complicated: I've listened five times to it, but I still wasn't able
to follow the score...


There's the rub...

Obviously, if I gave this score to 10 highly-skilled amateur chamber 
choirs and said "have at it," I would get 10 very different versions of 
the piece and probably none of them would resemble the recording 
(whether or not they'd be better is another question).  However, if I 
put more vague indications like "freak out in the style of Mike 
Solomon," while this would probably get a better initial result 
(assuming the person took the time to research how I freak out), it 
would max out at a lower level of interesting nuance and unexpected 
concord.


If you listen to each voice solo-ed out with a click track, you'll see 
that the recording is pretty much a sonic carbon copy of the notation.  
The best way to learn the piece, then, is to learn it by ear as you read 
it on a beat-by-beat basis.  After rehearsing it this way, the score the 
acts as a timeline with various landmarks to jog your muscle memory.




Any chance to make it more simple?  Obviously,
you know far too much about lilypond to produce such well looking
scores :-)



I <3 LilyPond (that's why I try to break it so often), and I shudder to 
think what putting this together would have been like with any other 
notation program.


Cheers,
MS

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

Re: OT: Vocal music

[Phil Holmes]

- Original Message - 
From: 

To: "Werner LEMBERG" 
Cc: ; ; 
; 

Sent: Friday, November 25, 2011 11:28 AM
Subject: Re: OT: Vocal music



On Fri, 25 Nov 2011 10:52:26 +0100 (CET), Werner LEMBERG wrote:

I'm working on a book of madrigals right now and some of it is
recorded.  The YouTube excerpt has affinities w/ mm. 21-30 of the
attached PDF & audio file (it's an excerpt from the 3rd madrigal in
the book, called "Lucky Wok (star!)").


Your sample sounds really amazing!  However, the notation is extremely
complicated: I've listened five times to it, but I still wasn't able
to follow the score...



Mike,

I'm guessing this was forwarded on from a different conversation.  Any 
chance of letting others see/hear the work?


--
Phil Holmes



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

Re: OT: Vocal music

[Werner LEMBERG]

> I'm guessing this was forwarded on from a different conversation.
> Any chance of letting others see/hear the work?

Oh, it's probably sitting in the mailing list queue because it was a
rather large email...


Werner

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

Re: OT: Vocal music

[Werner LEMBERG]

> I've attached a couple images of various movements that are already
> done to whet your appetite (or to help you lose it depending on
> where you stand).

I would *love* to see your code!  Scores 1 and 3 again look very
amazing.


Werner

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

LSR updates and Issue 1971

[Phil Holmes]

I've got a large patch that updates the snippets from the LSR and fixes 
Issue 1971.  It's a few hundred files.  make and make doc are fine after 
adding it.  Should I push to staging or do something like a review - it 
seems unlikely anyone will have the enthusiasm to review all 300-odd changed 
files.


--
Phil Holmes



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

Re: LSR updates and Issue 1971

[Carl Sorensen]

On 11/25/11 10:59 AM, "Phil Holmes"  wrote:

>I've got a large patch that updates the snippets from the LSR and fixes
>Issue 1971.  It's a few hundred files.  make and make doc are fine after
>adding it.  Should I push to staging or do something like a review - it
>seems unlikely anyone will have the enthusiasm to review all 300-odd
>changed 
>files.

What do you mean by "updates the snippets from the LSR"?  Snippets from
the LSR should be fixed in the LSR.  Snippets that can't be the same as in
the LSR (due to changes in the version) should be in
Documentation/snippets/new.  But why are there 300-odd changed files?

More information would certainly be helpful to understand this issue.

Thanks,

Carl




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

Re: LSR updates and Issue 1971

[Phil Holmes]

- Original Message - 
From: "Carl Sorensen" 

To: "Phil Holmes" ; "Devel" 
Sent: Friday, November 25, 2011 6:35 PM
Subject: Re: LSR updates and Issue 1971





On 11/25/11 10:59 AM, "Phil Holmes"  wrote:


I've got a large patch that updates the snippets from the LSR and fixes
Issue 1971.  It's a few hundred files.  make and make doc are fine after
adding it.  Should I push to staging or do something like a review - it
seems unlikely anyone will have the enthusiasm to review all 300-odd
changed
files.


What do you mean by "updates the snippets from the LSR"?  Snippets from
the LSR should be fixed in the LSR.  Snippets that can't be the same as in
the LSR (due to changes in the version) should be in
Documentation/snippets/new.  But why are there 300-odd changed files?

More information would certainly be helpful to understand this issue.

Thanks,

Carl


It's a snippet in snippets/new, since it doesn't run on 2.12.  To correct 
these, you need to correct the snippet in snippets/new and then run makelsr 
to get the correct version into snippets/.   To run makelsr you have to have 
downloaded the latest LSR tarball, and so running the updates on this causes 
them all (I think) to be changed because convert-ly is run.  So every 
snippet is changed, which makes for a large patch.


Some information at:

http://lilypond.org/doc/v2.15/Documentation/contributor-big-page#lsr-to-git

I think Valentin used to run makelsr, but it's not been done for a while.

--
Phil Holmes



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

Re: 2 pushes to dev/staging

[Graham Percival]

On Thu, Nov 24, 2011 at 09:09:14AM +0100, m...@apollinemike.com wrote:
> Could someone please verify that they are indeed in staging
> (111f4707f90a4512f2c945ee5a47510c210b45f9 and
> 006a7e62037188718465427626174af5b6f03a1d)?

I see that this is resolved now, and hopefully in a few days I'll
get instructions in the CG... but as a temporary note, remember
that you can always check with the webgit interface.
http://git.savannah.gnu.org/gitweb/?p=lilypond.git

- Graham

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

Re: LSR updates and Issue 1971

[Carl Sorensen]

On 11/25/11 11:46 AM, "Phil Holmes"  wrote:

>- Original Message -
>From: "Carl Sorensen" 
>To: "Phil Holmes" ; "Devel" 
>Sent: Friday, November 25, 2011 6:35 PM
>Subject: Re: LSR updates and Issue 1971
>
>
>>
>>
>> On 11/25/11 10:59 AM, "Phil Holmes"  wrote:
>>
>>>I've got a large patch that updates the snippets from the LSR and fixes
>>>Issue 1971.  It's a few hundred files.  make and make doc are fine after
>>>adding it.  Should I push to staging or do something like a review - it
>>>seems unlikely anyone will have the enthusiasm to review all 300-odd
>>>changed
>>>files.
>>
>> What do you mean by "updates the snippets from the LSR"?  Snippets from
>> the LSR should be fixed in the LSR.  Snippets that can't be the same as
>>in
>> the LSR (due to changes in the version) should be in
>> Documentation/snippets/new.  But why are there 300-odd changed files?
>>
>> More information would certainly be helpful to understand this issue.
>>
>> Thanks,
>>
>> Carl
>
>It's a snippet in snippets/new, since it doesn't run on 2.12.  To correct
>these, you need to correct the snippet in snippets/new and then run
>makelsr 
>to get the correct version into snippets/.   To run makelsr you have to
>have 
>downloaded the latest LSR tarball, and so running the updates on this
>causes 
>them all (I think) to be changed because convert-ly is run.  So every
>snippet is changed, which makes for a large patch.

For this patch, go ahead and push, as long as make doc works.

For the future, I think you can run makelsr.py with downloading the latest
LSR tarball (at least I have in the past), and that will get the changed
snippets into the docs *without* changing all the files.

IIUC, as part of the release process for a new version, we ought to do a
makelsr.py, which should run convert-ly on the snippets.  That commit
should be separate from one that requires manual editing of snippets.  The
makelsr.py-run patch does not require review.

Thanks,

Carl


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

Re: LSR updates and Issue 1971

[Graham Percival]

On Fri, Nov 25, 2011 at 05:59:04PM -, Phil Holmes wrote:
> I've got a large patch that updates the snippets from the LSR and
> fixes Issue 1971.  It's a few hundred files.  make and make doc are
> fine after adding it.  Should I push to staging or do something like
> a review - it seems unlikely anyone will have the enthusiasm to
> review all 300-odd changed files.

Excellent!

I'd personally prefer to split it into 2 separate commits:
1. run makelsr.py locally (i.e. don't point it at your tarball).

this will update the GIT_COMMITISH for every single file.  Quite
annoying, pollutes the history, but apparently translators need
that.

if you skim over the patch in gitk, you shouldn't see anything
weird.  commit that and push directly to staging.

2. run makelsr.py and point at the downloaded LSR directory.

look at that patch more carefully, then please upload it for
review -- there should be 1-20 changed files.  Maybe 30.
we won't bother with a full countdown, but I'd like to skim it
before you push it.

- Graham

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

Re: Asserts that footnotes are being numbered correctly. (issue 5433065)

[pkx166h]

Passes make and make check

James

http://codereview.appspot.com/5433065/

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

Re: Uses the pure-from-neighbor-interface for NonMusicalPaperColumn horizontal spacing. (issue 5432070)

[pkx166h]

Passes Make, all reg test diffs here

http://code.google.com/p/lilypond/issues/detail?id=2053#c1

James

http://codereview.appspot.com/5432070/

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

Re: Uses the pure-from-neighbor-interface for NonMusicalPaperColumn horizontal spacing. (issue 5432070)

[pkx166h]

On 2011/11/25 05:31:57, MikeSol wrote:

Sorry, forgot to mention that for the time being this only applies

cleanly to

the staging branch.  It'll apply cleanly to master once master is
fast-forwarded.


I fast forwarded staging ;)

http://codereview.appspot.com/5432070/

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

Re: Better pure heights for slurs (issue 5431065)

[pkx166h]

Passes Make and reg tests are here

http://code.google.com/p/lilypond/issues/detail?id=2051#c6

james

http://codereview.appspot.com/5431065/

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

Make 2-argument form of \accidentalStyle (issue 5432077)

[pkx166h]

Passes Make and make check

James

http://codereview.appspot.com/5432077/

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

Segfaults involving fret diagrams

[Carl Sorensen]

David,

There have been a number of crashes involving fret diagrams when used in
lilypond book and multiple runs, for example

and


With Mike's recent discovery that non-documented property gets/sets can
lead to memory leaks, I decided to check out the properties in the fret
diagram markups.

On line 1085 of scm/fret-diagrams.scm, you added a line for the properties
of a fret-diagram-terse markup; the properties entry is
(fret-diagram-verbose-markup).

I don't understand how this properly sets the properties for a terse
diagram, and wonder if this might be responsible for the fret diagrams
crashes.  Can you shed any light on this behavior?

Thanks,

Carl



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

Re: Uses the pure-from-neighbor-interface for NonMusicalPaperColumn horizontal spacing. (issue 5432070)

[k-ohara5a5a]

looks good to me,
 after putting back skyline-vertical-padding for just one more round.


http://codereview.appspot.com/5432070/diff/1/input/regression/lyrics-pass-under-bar.ly
File input/regression/lyrics-pass-under-bar.ly (right):

http://codereview.appspot.com/5432070/diff/1/input/regression/lyrics-pass-under-bar.ly#newcode5
input/regression/lyrics-pass-under-bar.ly:5: the bar line.
Can't put this in yet, because the BarLines don't yet distinguish
between items from their home staff, and other staves like Lyrics.

http://codereview.appspot.com/5432070/diff/1/scm/define-grobs.scm
File scm/define-grobs.scm (left):

http://codereview.appspot.com/5432070/diff/1/scm/define-grobs.scm#oldcode1413
scm/define-grobs.scm:1413: (skyline-vertical-padding . 0.6)
Can't take this out yet, or ledgers will go over bar lines.

http://codereview.appspot.com/5432070/diff/1/scm/define-grobs.scm
File scm/define-grobs.scm (right):

http://codereview.appspot.com/5432070/diff/1/scm/define-grobs.scm#newcode1091
scm/define-grobs.scm:1091: (KeyCancellation
This one, too

http://codereview.appspot.com/5432070/

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

Fix issue 1900 -- multiple fret-diagram-terse markups commands crash (issue 5432081)

[Carl . D . Sorensen]

Reviewers: ,

Message:
I've created a patch for Issue 1900.  It solves the crash, but perhaps
in a non-optimal way.

David, will you please review this, since I've changed code that you
added to scm/fret-diagrams.scm?

Thanks,

Carl


Description:
Fix issue 1900 -- multiple fret-diagram-terse markups commands crash

This fix uses an explicit definition of the default properties for
fret-diagram-terse and fret-diagram markups, instead of copying those
from the fret-diagram-verbose markup.

No regression test will be included, since it requires a special
lilypond-book call to test.  But the Lilypond issue will have a
regression test file posted.

Please review this at http://codereview.appspot.com/5432081/

Affected files:
  M scm/fret-diagrams.scm


Index: scm/fret-diagrams.scm
diff --git a/scm/fret-diagrams.scm b/scm/fret-diagrams.scm
index  
9247a115f70696dc444c1f6264abe59daa636150..09d2881525a602035480b5f328aeedbc8f301592  
100644

--- a/scm/fret-diagrams.scm
+++ b/scm/fret-diagrams.scm
@@ -1004,7 +1004,10 @@ indications per string.
 (define-markup-command (fret-diagram layout props definition-string)
   (string?) ; argument type
   #:category instrument-specific-markup ; markup category
-  #:properties (fret-diagram-verbose-markup) ; properties and defaults
+  #:properties ((align-dir -0.4) ; properties and defaults
+   (size 1.0)
+   (fret-diagram-details)
+   (thickness 0.5))
   "Make a (guitar) fret diagram.  For example, say

 @example
@@ -1082,7 +1085,10 @@ Note: There is no limit to the number of fret  
indications per string.

   (fret-diagram-terse layout props definition-string)
   (string?) ; argument type
   #:category instrument-specific-markup ; markup category
-  #:properties (fret-diagram-verbose-markup) ; properties
+  #:properties ((align-dir -0.4) ; properties and defaults
+   (size 1.0)
+   (fret-diagram-details)
+   (thickness 0.5))
   "Make a fret diagram markup using terse string-based syntax.

 Here is an example



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

Re: Better pure heights for slurs (issue 5431065)

[k-ohara5a5a]

On 2011/11/25 05:01:39, mike_apollinemike.com wrote:

On Thu, 24 Nov 2011 19:16:46 +, mailto:k-ohara5...@oco.net wrote:
> I like the direction of this change.



Does it actually work?


It used to.  You should try your patches, occasionally.
Take Carl's example from

and replace his debugging \paper block with
 \paper{ annotate-spacing = ##t ragged-bottom = ##t}

The good versions space this nicely on 4 pages.  (Patch set 3 uses 35
pages.)


http://codereview.appspot.com/5431065/diff/5003/lily/slur.cc
File lily/slur.cc (right):

http://codereview.appspot.com/5431065/diff/5003/lily/slur.cc#newcode101
lily/slur.cc:101: ret[downup] = minmax (downup, d[dir], ret[dir]);
?? ret.add_point(d[dir]);

http://codereview.appspot.com/5431065/diff/5003/lily/slur.cc#newcode106
lily/slur.cc:106: extremal_heights[RIGHT] = d[dir];
extremal_heights[LEFT (Right)] holds the position of the slur-side end
of the first (respectively, last) nonempty encompassed grob we found.

http://codereview.appspot.com/5431065/diff/5003/lily/slur.cc#newcode113
lily/slur.cc:113: // we dampen the height approximation by the slur's
likely slope
But why bother?  height_approximation is typically 0.3 staff-space, and
always vertical even if the slur slopes?

http://codereview.appspot.com/5431065/diff/5003/lily/slur.cc#newcode119
lily/slur.cc:119: 0.5 staff spaces from the note-head.
Should this 0.5 have been free-height-distance all along?

http://codereview.appspot.com/5431065/

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

Re: Better pure heights for slurs (issue 5431065)

[k-ohara5a5a]

On 2011/11/26 01:42:33, Keith wrote:

On 2011/11/25 05:01:39, http://mike_apollinemike.com wrote:
>
> Does it actually work?



It used to.


I take that back.  The override you emailed a while back setting
pure-height = 0  worked great, but none of these patches help much.

The patch based on my comments failed miserably because I forgot to cast
the unsigned vsize(no_elts) to (int).  I'll run `make check
Maybe the *0.5 was converting

http://codereview.appspot.com/5431065/

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

Re: Better pure heights for slurs (issue 5431065)

[k-ohara5a5a]

On 2011/11/26 01:42:33, Keith wrote:

On 2011/11/25 05:01:39, http://mike_apollinemike.com wrote:
>
> Does it actually work?



It used to.


I take that back.  The override you emailed a while back setting
pure-height = 0
 worked great, but none of these patches help much.

The patch based on my comments failed miserably because I forgot to cast
the unsigned vsize(no_elts) to (int).

Maybe the *0.5 was converting half-staff-spaces to staff-spaces

http://codereview.appspot.com/5431065/

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

Re: Better pure heights for slurs (issue 5431065)

[k-ohara5a5a]

On 2011/11/26 02:09:57, Keith wrote:

Maybe the *0.5 was converting half-staff-spaces to staff-spaces

No; the units are fine.

The problem seems to be not so much the overestimate of the slur extent,
but that said overestimate of space is allowed before each each script
with avoid-slur 'outside :

\paper{ annotate-spacing = ##t }
  \layout { \context { \Score
  \override PaperColumn #'stencil = #ly:separation-item::print
 }} #(ly:set-option 'debug-skylines)
{ b2( d')_>_\downbow_3 }

http://codereview.appspot.com/5431065/

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

Re: Segfaults involving fret diagrams

[David Kastrup]

Carl Sorensen  writes:

> David,
>
> There have been a number of crashes involving fret diagrams when used in
> lilypond book and multiple runs, for example
> 
> and
> 
>
> With Mike's recent discovery that non-documented property gets/sets can
> lead to memory leaks, I decided to check out the properties in the fret
> diagram markups.
>
> On line 1085 of scm/fret-diagrams.scm, you added a line for the properties
> of a fret-diagram-terse markup; the properties entry is
> (fret-diagram-verbose-markup).
>
> I don't understand how this properly sets the properties for a terse
> diagram, and wonder if this might be responsible for the fret diagrams
> crashes.  Can you shed any light on this behavior?

No.  My change was a purely mechanical one to accommodate new syntax.
Tracking this line leads to another commit of yours where you add a
comment for it.  But the actually responsible commit appears to be

commit 79aa415228f9193801a7d31aa595a0411f19288b
Author: Nicolas Sceaux 
Date:   Sun Apr 27 18:56:36 2008 +0200

Markup command documentation: categories and properties

Add a category argument to define-builtin-markup-command,
so that markup commands are sorted by categories in the documentation.
Also add a properties argument, which is used in the markup command
code to create bindings (extracting the properties from the props
argument), and in the documentation to list the used properties.


-- 
David Kastrup

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

Re: Fix issue 1900 -- multiple fret-diagram-terse markups commands crash (issue 5432081)

[David Kastrup]

carl.d.soren...@gmail.com writes:

> Reviewers: ,
>
> Message:
> I've created a patch for Issue 1900.  It solves the crash, but perhaps
> in a non-optimal way.
>
> David, will you please review this, since I've changed code that you
> added to scm/fret-diagrams.scm?

You are saying that the copying of properties does not work?  I have to
review that code.  I seem to remember (but might be mistaken) that I
might have _removed_ this feature at one point of time because it
appeared unused and the code was quite awful.

-- 
David Kastrup

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

Re: Fix issue 1900 -- multiple fret-diagram-terse markups commands crash (issue 5432081)

[David Kastrup]

David Kastrup  writes:

> carl.d.soren...@gmail.com writes:
>
>> Reviewers: ,
>>
>> Message:
>> I've created a patch for Issue 1900.  It solves the crash, but perhaps
>> in a non-optimal way.
>>
>> David, will you please review this, since I've changed code that you
>> added to scm/fret-diagrams.scm?
>
> You are saying that the copying of properties does not work?  I have to
> review that code.  I seem to remember (but might be mistaken) that I
> might have _removed_ this feature at one point of time because it
> appeared unused and the code was quite awful.

Does not look removed.  I might have just discussed this step in the
mailing list.  Reviewing it right now.

-- 
David Kastrup

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

Re: Fix issue 1900 -- multiple fret-diagram-terse markups commands crash (issue 5432081)

[dak]

On 2011/11/26 06:39:45, dak wrote:


Does not look removed.  I might have just discussed this step in the
mailing list.  Reviewing it right now.


The functionality seems to be there just fine.  What makes you suspect
that this copying-of-properties-at-definition-and-documentation-time is
responsible for a crash?

Mind you, the "copying of properties" puts the whole referred function
into the properties documentation (not just a symbol or so) which is
kind of icky.  It does have the advantage that it makes it close to
impossible to accidentally create recursive references.

http://codereview.appspot.com/5432081/

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