Re: Failed compiling a single lsr-snippet, which does not fail when running the whole lsr

[Graham Percival]

On Tue, Apr 03, 2012 at 02:06:37AM +0200, Thomas Morley wrote:
> > Contemporary vibrato is a total hack (it was one of the 1st things I wrote 
> > in LilyPond).  It's a miracle that it ever compiled in the first place.  I 
> > have a 2.15-friendly version I've been using lying around somewhere that is 
> > slightly less hackish.  Gimme a couple days to dig it out and I'll send it 
> > to you.
> 
> Thanks, that would be very nice, at least to put it in the LSR after
> it's 2.16. update. Do you think you can make it work with 2.14.2 ?

Not worth it; just delete that snippet.

- Graham

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

Re: Update Rietveld patches

[Colin Campbell]

On 12-04-02 04:18 PM, Łukasz Czerwiński wrote:
Well, I must say that I don't understand what I'm expected to 
do. Could you please explain me once more and say also what 
"Apparently replaced by R 5975074, pls add issue nbr to summary" 
means? Especially "add issue *nbr* to summary".


Łukasz

On 2 April 2012 03:53, Colin Campbell > wrote:


The items below are the result of a search on Rietveld for open
items associated with the lilypond trunk.  In some cases, the
tracker item has been closed, so the Rietveld item should also be
closed.  In others, work continues but it would be good to
cross-reference the tracker item in the Rietveld item summary or
title.




58620522310Milimetr88 Corrected style of comments 
Apparently replaced by R 5975074, pls add issue nbr to summary




Good to meet you, Łukasz, at least by email!

Our patch tracking system has two parts: one part is hosted on the 
Rietveld site, at codereview.appspot.com. The code review process allows 
us to use special tools, such as diff comparisons, to encourage and 
record discussion among developers regarding a proposed patch. The 
Rietveld tool assigns an issue number when a patch is first created, and 
later changes are attached as changes to the original. Your first upload 
created issue 5862502 on Rietveld. After some discussion, and possibly a 
glitch in using git-cl, a new issue, number 5975054, got created on 
Rietveld, leaving the older one still open. As you are the owner, and if 
I am correct that the new one replaces the first, that you should go 
onto Rietveld and update 5862502 to say it was replaced by 5975054, then 
mark 5862052 "closed".


The second part of my request was to go to 5975054 and update either the 
title or the summary to mention Issue 2310. That is because the Reitveld 
tool handles code patches well, but cannot track any other kind of 
issue, such as requests for changes, bug reports and other things which 
might not lead to code patches. The issue tracker on 
code.google.com/lilypond has a very usable interface, and works well for 
tracking various kinds of issues and their status. It, too, assigns a 
number when an issue is created, usually by the Bug Squad in response to 
a bug report. Developers also create issues, to announce enhancements 
for example, and this is how Janek created issue 2310, to document the 
work you and he are doing.


Tools which we have written for the purpose are aware of the two 
unconnected sources of information about patches and have been modified 
to allow you to refer to an existing issue number (2310) when uploading 
a patch to Rietveld (5975054), but this only handles one side of the 
connection: in the Google issue, the Rietveld issue number is added, but 
the only way to get the connection from Rietveld, at least at the moment 
and as far as I understand it, is to ask the developer to refer to the 
Google tracker number in the title or summary of the issue. You might, 
for example, simply change the title of 5975054 to " T2310 Corrected 
comments and a function check_meshing_chords divided in two" and it 
would be clear at a glance where the rest of the conversation can be found.


I hope that rather lengthy explanation helps, Łukasz, and do forgive my 
error in my first email, referring to 5975074 when it should have been 
5975054!


Cheers,
Colin the Elder

--
I've learned that you shouldn't go through life with a catcher's mitt on both 
hands.
You need to be able to throw something back.
-Maya Angelou, poet (1928- )

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

Re: Failed compiling a single lsr-snippet, which does not fail when running the whole lsr

[Thomas Morley]

Am 3. April 2012 01:51 schrieb m...@apollinemike.com :
> On Apr 3, 2012, at 1:26 AM, Thomas Morley wrote:
>
>> Hi,
>>
>> Seba just informed me that the "Contemporary vibrato" snippet is not 
>> compiling.
>>
>
> Contemporary vibrato is a total hack (it was one of the 1st things I wrote in 
> LilyPond).  It's a miracle that it ever compiled in the first place.  I have 
> a 2.15-friendly version I've been using lying around somewhere that is 
> slightly less hackish.  Gimme a couple days to dig it out and I'll send it to 
> you.

Thanks, that would be very nice, at least to put it in the LSR after
it's 2.16. update. Do you think you can make it work with 2.14.2 ?

Though, I'm very astonished that it compiles running all files of a
large directory, but not alone.

-Harm

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

Re: Failed compiling a single lsr-snippet, which does not fail when running the whole lsr

[m...@apollinemike.com]

On Apr 3, 2012, at 1:26 AM, Thomas Morley wrote:

> Hi,
> 
> Seba just informed me that the "Contemporary vibrato" snippet is not 
> compiling.
> 

Contemporary vibrato is a total hack (it was one of the 1st things I wrote in 
LilyPond).  It's a miracle that it ever compiled in the first place.  I have a 
2.15-friendly version I've been using lying around somewhere that is slightly 
less hackish.  Gimme a couple days to dig it out and I'll send it to you.

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

Failed compiling a single lsr-snippet, which does not fail when running the whole lsr

[Thomas Morley]

Hi,

Seba just informed me that the "Contemporary vibrato" snippet is not compiling.

(1) I tested again compiling the whole lsr with:

#!/bin/bash

for LILYFILE in *.ly
do
  STEM=$(basename "$LILYFILE" .ly)
  echo "running $LILYFILE..."
  lilypond --format=png -ddelete-intermediate-files "$LILYFILE" >& "$STEM".txt
done

and it works fine.

(2) I tested compiling the whole lsr with:

lilypond *.ly

and it works fine.

(3) But running the single file failes. I've no idea what's going on.


File attached.


Cheers,
  Harm


contemporary-vibrato.ly
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Bloody mao! Valentin, you tricked us!

[Valentin Villenave]

On Tue, Apr 3, 2012 at 12:07 AM, Janek Warchoł  wrote:
> Valentin, you sneaky bastard!  Tried to deceive us, huh?  But i see
> the new LilyPond Report announced on Lily website, mwahahahaha!
> http://news.lilynet.net/?The-LilyPond-Report-25&lang=en
> Janek ;-)

Yeah, that's me all right :-)

Cheers -- and thanks for all the fish,
Valentin.

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

Re: Update Rietveld patches

[Łukasz Czerwiński]

Well, I must say that I don't understand what I'm expected to do. Could you
please explain me once more and say also what "Apparently replaced by R
5975074, pls add issue nbr to summary" means? Especially "add issue
*nbr*to summary".

Łukasz

On 2 April 2012 03:53, Colin Campbell  wrote:

>  The items below are the result of a search on Rietveld for open items
> associated with the lilypond trunk.  In some cases, the tracker item has
> been closed, so the Rietveld item should also be closed.  In others, work
> continues but it would be good to cross-reference the tracker item in the
> Rietveld item summary or title.
>
> *RietveldIssueOwner   Description (short)
> status  *
>
> 56741012333 Rienhold  extract_texi_filenames.py   fixed, 
> verified: please close Rietveld
>
> 56900552337 Pal Benko avoid infinite loop fixed 
> and verified, please close Rietveld
>
> 56950612350 Joe NeemanSimplify font building. Work in 
> progress, please add Issue nbr to Rietveld summary
>
> 57150532371 Pavel Roskin  Fix crash unknown grob name Work in 
> progress, please add Issue nbr to Rietveld summary
>
> 57270512344 Alexandr A.   Fixing height of Kievan bar lineWork in 
> progress, please add Issue nbr to Rietveld summary
>
> 57840842406 Peter Chubb   Fix mordents,pralltriller   fixed, 
> please close Rietveld
>
> 58150432230Julien Rioux   Add regtest dir svg output  Work in 
> progress.
>
> 58460752423Julien Rioux   ly-book Set include path
> Patch-Push 20120331
>
> 58620522310Milimetr88 Corrected style of comments 
> Apparently replaced by R 5975074, pls add issue nbr to summary
>
> 58820532427P.  Roskin Add an example cross-staff stems
> Patch-Push 20120331
>
>
> At the moment, I have no simple way of scanning Rietveld items which do
> not have their base URL set to
> http://git.savannah.gnu.org/gitweb/?p=lilypond.git/trunk/ and I would be
> most grateful if the devels who have patches on Rietveld would find a few
> moments to update them by adding the base URL and if at all possible, the
> tracker number to which the patch belongs.
>
> Cheers,
>
> Colin
>
> -- I've learned that you shouldn't go through life with a catcher's mitt
> on both hands. You need to be able to throw something back.
>  -Maya Angelou, poet (1928- )
>
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
>
>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Bloody mao! Valentin, you tricked us!

[Janek Warchoł]

Valentin, you sneaky bastard!  Tried to deceive us, huh?  But i see
the new LilyPond Report announced on Lily website, mwahahahaha!
http://news.lilynet.net/?The-LilyPond-Report-25&lang=en
Janek ;-)

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

Re: Doc: CG Update compile.itexi for doc build (issue 5967060)

[tdanielsmusic]

LGTM
Trevor

http://codereview.appspot.com/5967060/

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

Re: No LilyPond Report today

[Ralph Palmer]

On Sun, Apr 1, 2012 at 5:33 PM, Valentin Villenave
wrote:

> Hello folks,
> you may have noticed that there **isn't** a new LilyPond Report out today.
>
> Nope. None at all. Sorry.
>
> And if anything, you will certainly **not** find it here:
>
> http://news.lilynet.net/?The-LilyPond-Report-25
>
> But I didn't tell you that.
>
> Cheers,
> Valentin.


Didn't read this until this morning. Almost had me fooled, there, Valentin.
I had to cancel my online order of an accordion; made it just in time!

Pondly,

Ralph

-- 
Ralph Palmer
Brattleboro, VT
USA
palmer.r.vio...@gmail.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: LSR is now on 2.14

[David Nalesnik]

Hi,

On Mon, Apr 2, 2012 at 11:48 AM, Phil Holmes  wrote:

> Sorry about the top post.  Windows mail is sometimes a pain.  I'll do
> fretted-string-harmonics... to screech-boink.
>
>
> Phil Holmes
>
>
>
> Attached the tarball with the missing files from
> `Ducumentatione/snippets/new/'
> I'll pick the following files and put them into the LSR:
>
> alternative-breve-note.ly
> changing-the-ambitus-gap.ly
> changing-the-number-of-**augmentation-dots-per-note.ly
> changing-the-size-of-woodwind-**diagrams.ly
> chordchanges-for-fretboards.ly
> chord-glissando-in-tablature.**ly 
> controlling-spanner-**visibility-after-a-line-break.**ly
> defining-an-engraver-in-**scheme-ambitus-engraver.ly
> dynamics-custom-text-spanner-**postfix.ly
> dynamics-text-spanner-postfix.**ly
> expressive-headword.ly
> figured-bass-headword.ly
> fretboards-alternate-tables.ly
>
> Cheers,
>  Harm
>
>
I just added the remaining files.  One thing: I kept the formatting in the
texidoc string because I noticed that this had been done in other
additions.  Should this be converted to HTML formatting?

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

Re: LSR is now on 2.14

[Phil Holmes]

Sorry about the top post.  Windows mail is sometimes a pain.  I'll do 
fretted-string-harmonics... to screech-boink.



Phil Holmes


- Original Message - 
From: "Thomas Morley" 

To: "Phil Holmes" 
Cc: "David Nalesnik" ; "lilypond-devel" 


Sent: Monday, April 02, 2012 5:05 PM
Subject: Re: LSR is now on 2.14


Am 2. April 2012 01:36 schrieb Thomas Morley 
:

Am 1. April 2012 22:23 schrieb Phil Holmes :

From: "Thomas Morley" 

I downloaded todays LSR-tarball and removed all unnecessary headers
and versions manually.
Compiling-tests showed no problems.
I'd like to create a new tarball and send it back to Sebastiano. What
do you think?



Wow. That's a lot of work. Thanks for this. Please send it to Sebastiano.




Done.

-Harm



Sebastiano accepted the new tarball and the LSR now runs with it.
I think this work is finished.


ad 2.
I'll be happy to take a share, too. I'll prepare a tarball with the
missing files.




Attached the tarball with the missing files from 
`Ducumentatione/snippets/new/'

I'll pick the following files and put them into the LSR:

alternative-breve-note.ly
changing-the-ambitus-gap.ly
changing-the-number-of-augmentation-dots-per-note.ly
changing-the-size-of-woodwind-diagrams.ly
chordchanges-for-fretboards.ly
chord-glissando-in-tablature.ly
controlling-spanner-visibility-after-a-line-break.ly
defining-an-engraver-in-scheme-ambitus-engraver.ly
dynamics-custom-text-spanner-postfix.ly
dynamics-text-spanner-postfix.ly
expressive-headword.ly
figured-bass-headword.ly
fretboards-alternate-tables.ly

Cheers,
 Harm


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

Re: LSR is now on 2.14

[Thomas Morley]

Am 2. April 2012 01:36 schrieb Thomas Morley :
> Am 1. April 2012 22:23 schrieb Phil Holmes :
>> From: "Thomas Morley" 
>>> I downloaded todays LSR-tarball and removed all unnecessary headers
>>> and versions manually.
>>> Compiling-tests showed no problems.
>>> I'd like to create a new tarball and send it back to Sebastiano. What
>>> do you think?
>>
>>
>> Wow.  That's a lot of work.  Thanks for this.  Please send it to Sebastiano.
>>
>>
>
> Done.
>
> -Harm


Sebastiano accepted the new tarball and the LSR now runs with it.
I think this work is finished.

>>> ad 2.
>>> I'll be happy to take a share, too. I'll prepare a tarball with the
>>> missing files.
>

Attached the tarball with the missing files from `Ducumentatione/snippets/new/'
I'll pick the following files and put them into the LSR:

alternative-breve-note.ly
changing-the-ambitus-gap.ly
changing-the-number-of-augmentation-dots-per-note.ly
changing-the-size-of-woodwind-diagrams.ly
chordchanges-for-fretboards.ly
chord-glissando-in-tablature.ly
controlling-spanner-visibility-after-a-line-break.ly
defining-an-engraver-in-scheme-ambitus-engraver.ly
dynamics-custom-text-spanner-postfix.ly
dynamics-text-spanner-postfix.ly
expressive-headword.ly
figured-bass-headword.ly
fretboards-alternate-tables.ly

Cheers,
  Harm


missing.tar.gz
Description: GNU Zip compressed data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: my GSoC application - please review! (also, who will be my mentor?)

[m...@apollinemike.com]

On Apr 2, 2012, at 5:05 PM, Janek Warchoł wrote:

> On Sun, Apr 1, 2012 at 1:55 PM, m...@apollinemike.com
>  wrote:
>> It's just the opposite - the use of technical details shows a lack of
>> clarity of understanding, as it attaches importance to things that may
>> change depending on the implementation as opposed to design.  Stay on the
>> design level.  I'd define early on the concepts of engraver and grob and
>> then use them as a ritornello.
>> 
>> GNU is not there to
>> finance other LilyPond developers - they're there to finance you.  You need
>> to be confident and assertive and sell yourself.  They need to have the
>> impression that you know exactly what you're doing, know exactly how you're
>> going to go about it, and that you're worth every penny of what you're going
>> to do.
> 
> Many thanks for the tips, Mike!  I attach the revised application at
> the bottom, and i will submit it later today (applications can be
> edited until deadline).

Looks good!  It's much more assertive and professional & it's an easier read as 
well.  Good luck!

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

Re: my GSoC application - please review! (also, who will be my mentor?)

[Janek Warchoł]

On Sun, Apr 1, 2012 at 1:55 PM, m...@apollinemike.com
 wrote:
> It's just the opposite - the use of technical details shows a lack of
> clarity of understanding, as it attaches importance to things that may
> change depending on the implementation as opposed to design.  Stay on the
> design level.  I'd define early on the concepts of engraver and grob and
> then use them as a ritornello.
>
> GNU is not there to
> finance other LilyPond developers - they're there to finance you.  You need
> to be confident and assertive and sell yourself.  They need to have the
> impression that you know exactly what you're doing, know exactly how you're
> going to go about it, and that you're worth every penny of what you're going
> to do.

Many thanks for the tips, Mike!  I attach the revised application at
the bottom, and i will submit it later today (applications can be
edited until deadline).

On Mon, Apr 2, 2012 at 2:05 AM, Carl Sorensen  wrote:
> I think you should be selected for GSoC.  You clearly meet all of the
> important metrics, and your work will be important for LilyPond.

Thanks for encouragement, Carl!

> I agree with everybody else's comments.
>
> I would be willing to be your backup mentor.

Thank you, i'm honoured!
Janek

Revised application:

My name:
Jan Warchoł
(I usually use form "Janek" to distinguish myself from Jan
Nieuwenhuizen in LilyPond community)
I study mechatronics on Warsaw University of Technology (first year).
I studied math for 2 years.

My email address:
janek.lilyp...@gmail.com

The name of the project:
LilyPond: improve Lyrics support

Summary:
LilyPond support for lyrics (words that are sung to the melody -
usually each syllabe is placed under it's respective note) is
currently similar to that of the two market leaders (Finale and
Sibelius) - users can add any number of lyric verses in any language
supported by UTF-8 encoding.  I want to add advanced lyric positioning
functions that will be unique to LilyPond; syllabes will be
automatically moved to faciliate easier sight reading for singers and
avoid any ambiguities in interpretation.  Lyric syllabes will no
longer casuse disturbances in note spacing - instead of moving notes
to fit lyrics, lyrics will adapt their position to allow for the
optimal note spacing.

Benefits:
Users will have their lyrics automatically typeset with a quality
equal to that of the best hand-engraved professional publications;
LilyPond's default lyric positioning will surpass that of any other
music notation program (including world market leaders such as Finale
and Sibelius).  There will be virtually no need for hard-coded manual
corrections, making scores easier to maintain and rearrange.

The GNU project will benefit from having a music engraving program
offering its users unique possibilities and a very efficient workflow.
 LilyPond is already delivering great typography, but producing
professional scores of such works as G. F. Handel's "Messiah" still
requires some manual corrections; better lyric positioning is one of
the few improvements needed to have LilyPond automatically produce
publication-quality scores of great works.

Deliverables:
I've prepared a detailed report on the features that are needed,
putting each feature into a separate issue for greater clarity.  The
issues are viewable in LilyPond's bug tracker:
http://code.google.com/p/lilypond/issues/list?q=label:GSoC-LyricProject
(so even if my application isn't accepted the community will benefit
by having a thourough report on the matter).
These features shouldn't be addressed separately; they are connected
to each other and a good solution must be based on a generic
architecture.  I will add new properties to Lyric objects, and also
ensure that when LilyPond calculates position of lyrics, she already
knows how the notes should be placed to achieve best results.  Thus,
while most of the changes will affect Lyrics class, fixing issues 2462
and 2450 will require modifications to horizontal note spacing
algorithm.
As for issue 2459, I will add a new type of context - a line that can
be broken into segments.  I will then add a command that will allow
users to choose breaking points - that's an easy thing to do.  Then,
when I finish other issues, I'll add advanced functionalities:
automatic breaking based on the gap between neighbor obejcts, the
difference between vertical baseline position, and overall vertical
tightness of music.

All new features will have regresstion tests.  Most of the tests are
already written - they're now added as examples in tracker issues.
Documentation - I'll have to list and describe new object properties,
contexts and functions in Internals Reference.  I'll explain how to
use new possibilities in notation reference, section 2.1.2 "Techniques
specific to lyrics"

Plan:
1. April 20th - May 1st: discuss general architecture design with my
mentor; list object properties and methods that need to be created.
Determine how to harvest information about horizontal spacing 

Re: Changes .tex files to get rid of warning (issue 5976055)

[Julien Rioux]

On Mon, Apr 2, 2012 at 11:11 AM, Phil Holmes  wrote:
> - Original Message - From: "Julien Rioux" 
> To: ; ;
> ; ; ;
> 
>
>> > A snippet with a deprecated option, triggering compatibility mode:
>> >
>> > -\lilypond[11pt,fragment]{c' e' g'}
>> > +\lilypond[staffsize=11,fragment]{c' e' g'}
>> >
>> > \end{document}
>>
>> This change to tex-compatibility-mode.tex makes no sense. The whole
>> point of this file is to test that deprecated options are still
>> supported.
>> --
>> Julien
>
>
> Excellent catch - thanks, Julien.  I was in auto-correct mode.  How do you
> suggest we correct this?  I doubt we want this warning displayed.
> run-and-check?
>
> --
> Phil Holmes
>
>

Yes I think run-and-check is fine for this.
--
Julien

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

Re: Changes .tex files to get rid of warning (issue 5976055)

[Phil Holmes]

- Original Message - 
From: "Julien Rioux" 
To: ; ; 
; ; ; 


> A snippet with a deprecated option, triggering compatibility mode:
>
> -\lilypond[11pt,fragment]{c' e' g'}
> +\lilypond[staffsize=11,fragment]{c' e' g'}
>
> \end{document}

This change to tex-compatibility-mode.tex makes no sense. The whole
point of this file is to test that deprecated options are still
supported.
--
Julien


Excellent catch - thanks, Julien.  I was in auto-correct mode.  How do you 
suggest we correct this?  I doubt we want this warning displayed. 
run-and-check?


--
Phil Holmes



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

Doc: CG Update compile.itexi for doc build (issue 5967060)

[julien . rioux]

LGTM

http://codereview.appspot.com/5967060/

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

Re: Changes .tex files to get rid of warning (issue 5976055)

[Julien Rioux]

On Sun, Apr 1, 2012 at 2:32 PM,   wrote:
> Reviewers: Julien Rioux, Graham Percival, dak,
>
> Message:
> Please review
>
> Description:
> These files used what appears to be a deprecated syntax to invoke
> lilypond-book, resulting in these warnings:
>
> lilypond-book.py: warning: deprecated ly-option used: 11pt=None
> lilypond-book.py: warning: compatibility mode translation: staffsize=11
>
> Applying these changes gets rid of those errors in make doc.
>
> Please review this at http://codereview.appspot.com/5976055/
>
> Affected files:
>  Documentation/usage/latex-lilypond-example.latex
>  M input/regression/lilypond-book/tex-comments.lytex
>  M input/regression/lilypond-book/tex-compatibility-mode.lytex
>  M input/regression/lilypond-book/tex-lilypond-inside-itemize.lytex
>  M input/regression/lilypond-book/tex-lilypond-inside-table.lytex
>
>
> Index: input/regression/lilypond-book/tex-compatibility-mode.lytex
> diff --git a/input/regression/lilypond-book/tex-compatibility-mode.lytex
> b/input/regression/lilypond-book/tex-compatibility-mode.lytex
> index
> aab288e7b3504e235b72706b45e27688cade59ca..933b7ec4fd7d82fbcffd231baf0ded51d8cc2c0e
> 100644
> --- a/input/regression/lilypond-book/tex-compatibility-mode.lytex
> +++ b/input/regression/lilypond-book/tex-compatibility-mode.lytex
> @@ -5,6 +5,6 @@
>
>  A snippet with a deprecated option, triggering compatibility mode:
>
> -\lilypond[11pt,fragment]{c' e' g'}
> +\lilypond[staffsize=11,fragment]{c' e' g'}
>
>  \end{document}

This change to tex-compatibility-mode.tex makes no sense. The whole
point of this file is to test that deprecated options are still
supported.
--
Julien

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

Re: Triggers X-extent calculation for NoteColumn before setting stem-begin-position (issue 5934050)

[mtsolo]

http://codereview.appspot.com/5934050/diff/7001/lily/stem.cc
File lily/stem.cc (right):

http://codereview.appspot.com/5934050/diff/7001/lily/stem.cc#newcode131
lily/stem.cc:131: Real stem_beg = internal_calc_stem_begin_position (me,
false);
On 2012/04/02 07:42:55, Keith wrote:

I'm assuming something within calc_stem_begin_position (me,

calc_beam=false)

triggers note-collision resolution before setting the stem-begin

position.

Yup.  It allows calc_stem_position to skip all of the beam business and
get to the setting of note positions.

http://codereview.appspot.com/5934050/

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

Re: Triggers X-extent calculation for NoteColumn before setting stem-begin-position (issue 5934050)

[k-ohara5a5a]

Works good for me.



http://codereview.appspot.com/5934050/diff/7001/lily/stem.cc
File lily/stem.cc (right):

http://codereview.appspot.com/5934050/diff/7001/lily/stem.cc#newcode131
lily/stem.cc:131: Real stem_beg = internal_calc_stem_begin_position (me,
false);
I'm assuming something within calc_stem_begin_position (me,
calc_beam=false) triggers note-collision resolution before setting the
stem-begin position.

http://codereview.appspot.com/5934050/

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