Re: CG: explanation of branches for the impatient (issue 5484043)

thanks, Keith! I've made all the changes other than the two noted below. http://codereview.appspot.com/5484043/diff/1/Documentation/contributor/source-code.itexi File Documentation/contributor/source-code.itexi (right): http://codereview.appspot.com/5484043/diff/1/Documentation/contributor/sou

Re: CG: explanation of branches for the impatient (issue 5484043)

Second draft uploaded; more robust with rebases instead of merge. Question: the old docs want translators to avoid rebasing for some reason. Is that reason still valid? Because it would be very nice if we didn't have to have a separate section of "git for translators". http://lilypond.org/doc/v

Re: CG: explanation of branches for the impatient (issue 5484043)

On 12/13/11 7:06 AM, "gra...@percival-music.ca" wrote: >Second draft uploaded; more robust with rebases instead of merge. > >Question: the old docs want translators to avoid rebasing for some >reason. Is that reason still valid? Because it would be very nice if >we didn't have to have a separ

Markup module patch (Issue 2026)

Hi all, The patch had to get pulled from staging as although it passed reg. tests it wouldn't compile the doc. I can easily fix the snippet in /Documentation/snippets/three-sided-box.ly, but this leaves one more problem in the docs, this time in /extending/. I pulled out and tested the examples i

Re: Markup module patch (Issue 2026)

On 12/13/11 12:56 PM, "Ian Hulin" wrote: >Hi all, >The patch had to get pulled from staging as although it passed reg. >tests it wouldn't compile the doc. I can easily fix the snippet in >/Documentation/snippets/three-sided-box.ly, but this leaves one more >problem in the docs, this time in /ext

Re: Markup module patch (Issue 2026)

Ian Hulin writes: > Hi all, > The patch had to get pulled from staging as although it passed reg. > tests it wouldn't compile the doc. I can easily fix the snippet in > /Documentation/snippets/three-sided-box.ly, but this leaves one more > problem in the docs, this time in /extending/. > > I pul

Re: Markup module patch (Issue 2026)

Carl Sorensen writes: > On 12/13/11 12:56 PM, "Ian Hulin" wrote: > >>Hi all, >>The patch had to get pulled from staging as although it passed reg. >>tests it wouldn't compile the doc. I can easily fix the snippet in >>/Documentation/snippets/three-sided-box.ly, So this patch has more than one

Re: CG: explanation of branches for the impatient (issue 5484043)

2011/12/13 Carl Sorensen : > > > On 12/13/11 7:06 AM, "gra...@percival-music.ca" > wrote: > >>Second draft uploaded; more robust with rebases instead of merge. >> >>Question: the old docs want translators to avoid rebasing for some >>reason.  Is that reason still valid?  Because it would be very n

Re: Markup module patch (Issue 2026)

On 12/13/11 4:42 PM, "David Kastrup" wrote: >Carl Sorensen writes: > >> On 12/13/11 12:56 PM, "Ian Hulin" wrote: >> >>>interpret-markup #{ \markup \markup-command #'par ... #} within a >>>#(define-markup-command ... ) block. I'd like to deprecate this as I >>>think it's nasty, smelly, evil an

Re: CG: explanation of branches for the impatient (issue 5484043)

2011/12/14 Francisco Vila : > 2011/12/13 Carl Sorensen : >> >> >> On 12/13/11 7:06 AM, "gra...@percival-music.ca" >> wrote: >>>Second draft uploaded; more robust with rebases instead of merge. >>> >>>Question: the old docs want translators to avoid rebasing for some >>>reason.  Is that reason stil

Re: Markup module patch (Issue 2026)

Hi David, On 13/12/11 22:40, David Kastrup wrote: > Ian Hulin writes: > >> Hi all, ..snip.. > > >> I'd like to deprecate this as I think it's nasty, smelly, evil >> and kludgy > > Care to explain why being able to use the same syntax as one uses > in the main document is nasty, smelly, evil an

PATCH: Countdown to 20111215

For 21:00 MST Thursday December 15 Documentation: Issue 2101 : Doc: NR Added glissando grob skip snippet to 1.3.3 - R 5482050 Enhancement: Issue 1377

Re: Markup module patch (Issue 2026)

Carl Sorensen writes: > What I meant to say was that I thought you would have some insight, > and be able to identify whether there were any issues with the #{ #} > syntax. The parser output shows that there are no issues with that > syntax, so we need to find a better way to handle this shift i