Re: [Enhancement] Update syntax automatically

2010-02-22 Thread Mats Bengtsson

Graham Percival wrote:

2010/2/19 Dénes Harmath harmathde...@gmail.com:
  

There should be an option in lilypond to invoke convert-ly on the files before
compiling. This way, the user doesn't have to care with updating the syntax of
her files manually; when updating LilyPond, files will be up to date
automatically when compiled.



convert-ly is not sufficiently automatic / foolproof to be worth doing
this.  Feel free to write a script that runs convert-ly -e before
calling lilypond, but this will not be added to the LilyPond project
itself.
  
Also, since the main LilyPond programmers work primarily with UNIX, they 
follow the UNIX paradigm of letting separate programs be responsible for 
separate tasks. As Graham said, combining the two into a single command 
is easily done using a script or could be included as an option into a 
development environment (such as LilypondTool, or the LilyPond mode of 
editors like Emacs or VIM).
Finally, I see several risks of confusions when using such an option. If 
it did convert-ly -e, then the file would have to be reloaded in the 
text editor, manually or automatically depending on what editor you use. 
If it instead kept the original file and let LilyPond process a 
temporary copy with updated syntax, then the warning/error messages 
would not point to relevant lines in the original file.


 /Mats

  /Mats

Cheers,
- Graham


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
  



--
=
Mats Bengtsson
Signal Processing
School of Electrical Engineering
Royal Institute of Technology (KTH)
SE-100 44  STOCKHOLM
Sweden
Phone: (+46) 8 790 8463 
   Fax:   (+46) 8 790 7260
Email: mats.bengts...@ee.kth.se
WWW: http://www.s3.kth.se/~mabe
=



___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond


Re: [Enhancement] Update syntax automatically

2010-02-22 Thread Bernard Hurley
On Mon, Feb 22, 2010 at 09:37:14AM +0100, Mats Bengtsson wrote:
 Graham Percival wrote:
 2010/2/19 Dénes Harmath harmathde...@gmail.com:
   
 There should be an option in lilypond to invoke convert-ly on the files 
 before
 compiling. This way, the user doesn't have to care with updating the syntax 
 of
 her files manually; when updating LilyPond, files will be up to date
 automatically when compiled.
 

   
 Also, since the main LilyPond programmers work primarily with UNIX, they  
 follow the UNIX paradigm of letting separate programs be responsible for  
 separate tasks. As Graham said, combining the two into a single command  
 is easily done using a script or could be included as an option into a  
 development environment (such as LilypondTool, or the LilyPond mode of  
 editors like Emacs or VIM).

This can already be done with Frescobaldi - One of it's menu options is update 
with convert-ly

Bernard



___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond


Issue 1018 in lilypond: colors in web-examples would be nice

2010-02-22 Thread lilypond

Status: Accepted
Owner: 
Labels: Type-Documentation Priority-Low Frog

New issue 1018 by percival.music.ca: colors in web-examples would be nice
http://code.google.com/p/lilypond/issues/detail?id=1018

Our web-Introduction-Examples page has red lines for Gregorian, but it
would be nice to add some more.  I think they would fit best in the
educational application.  Or maybe in the Schenkerian analysis?

Frog: 30 minutes.

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond


Re: Issue 963 in lilypond: check dependency versions

2010-02-22 Thread lilypond


Comment #5 on issue 963 by v.villenave: check dependency versions
http://code.google.com/p/lilypond/issues/detail?id=963

IWBN if we could make the guile 2.0 upgrade coincide with our next major  
version bump

(aka Lily 3.0), wouldn't it?

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond


Re: Issue 963 in lilypond: check dependency versions

2010-02-22 Thread lilypond


Comment #6 on issue 963 by percival.music.ca: check dependency versions
http://code.google.com/p/lilypond/issues/detail?id=963

No it wouldn't -- then people wouldn't be able to take advantage of it  
without

spending hours rewriting their scores.

2.16 will use guile 2.0 (unless it's delayed beyond reasonable  
expectations).  Then

we can have a few months of stabilization with it before 3.0.

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond


Re: Issue 774 in lilypond: wrong horizontal trill position in small staff lines

2010-02-22 Thread lilypond

Updates:
Status: Started
Owner: n.puttock

Comment #8 on issue 774 by n.puttock: wrong horizontal trill position in  
small staff lines

http://code.google.com/p/lilypond/issues/detail?id=774

(No comment was entered for this change.)

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond


Re: T405 - Respect user setting bracket-visibility property. (issue194095)

2010-02-22 Thread Ian Hulin

On 20/02/10 17:27, n.putt...@gmail.com wrote:

Hi Ian,

Looks OK, though don't you think it would be better to increase the size
of the bracket if it's too small?

We--ll, yes, but that's not what this bug report is about.  As it's 
something you've picked up during the review it's strictly speaking a 
new issue.


Sorry if this sounds a bit jobsworth but I'd rather this patch went out 
the door as is and I'll look at your comment as part of work on a new 
tracker.


Cheers,

Ian



___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond


make warning

2010-02-22 Thread Jean-Charles Malahieude

Just for information, on master branch:

out/lilysong:26: DeprecationWarning: The popen2 module is deprecated. 
Use the subprocess module.





___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond


Re: T405 - Respect user setting bracket-visibility property. (issue194095)

2010-02-22 Thread n . puttock

On 2010/02/22 18:27:19, Ian Hulin wrote:


Sorry if this sounds a bit jobsworth but I'd rather this patch went

out

the door as is and I'll look at your comment as part of work on a new
tracker.


Fair enough.  Send me the patch when you've sorted the nitpicks below.

Cheers,
Neil

http://codereview.appspot.com/194095/show


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond


Re: T405 - Respect user setting bracket-visibility property. (issue194095)

2010-02-22 Thread n . puttock

Sorry, here they are:


http://codereview.appspot.com/194095/diff/2001/1003
File lily/tuplet-bracket.cc (right):

http://codereview.appspot.com/194095/diff/2001/1003#newcode4
lily/tuplet-bracket.cc:4: Copyright (C) 1997--2009 Jan Nieuwenhuizen
jann...@gnu.org
rebase again?

http://codereview.appspot.com/194095/diff/2001/1003#newcode287
lily/tuplet-bracket.cc:287: FIXME: The type of this prop is sucky.
indent

http://codereview.appspot.com/194095/show


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond


Re: [frogs] Re: T405 - Respect user setting bracket-visibility property. (issue194095)

2010-02-22 Thread Ian Hulin

Hi Neil,

Here's the amended patch.

Cheers,

Ian

On 22/02/10 22:17, n.putt...@gmail.com wrote:

On 2010/02/22 18:27:19, Ian Hulin wrote:


Sorry if this sounds a bit jobsworth but I'd rather this patch went

out

the door as is and I'll look at your comment as part of work on a new
tracker.


Fair enough.  Send me the patch when you've sorted the nitpicks below.

Cheers,
Neil

http://codereview.appspot.com/194095/show

---

Join the Frogs!


__   This email has 
been scanned by Netintelligence   
http://www.netintelligence.com/email





From ec0a781687878942995c3259b678fff17b58c666 Mon Sep 17 00:00:00 2001
From: Ian Hulin i...@hulin.org.uk
Date: Tue, 23 Feb 2010 00:17:21 +
Subject: [PATCH] T405 - Respect setting bracket-visibility property.

---
 lily/tuplet-bracket.cc |   47 +++
 1 files changed, 27 insertions(+), 20 deletions(-)

diff --git a/lily/tuplet-bracket.cc b/lily/tuplet-bracket.cc
index 76e249e..f525ef9 100644
--- a/lily/tuplet-bracket.cc
+++ b/lily/tuplet-bracket.cc
@@ -137,10 +137,10 @@ Tuplet_bracket::calc_connect_to_neighbors (SCM smob)
 {
   Spanner *me = unsmob_spanner (smob);
 
-  Direction dir = get_grob_direction (me); 
+  Direction dir = get_grob_direction (me);
   Drul_arrayItem * bounds (get_x_bound_item (me, LEFT, dir),
 			 get_x_bound_item (me, RIGHT, dir));
-  
+
   Drul_arraybool connect_to_other (false, false);
   Direction d = LEFT;
   do
@@ -169,11 +169,11 @@ Tuplet_bracket::calc_connect_to_neighbors (SCM smob)
   if (connect_to_other[LEFT] || connect_to_other[RIGHT])
 return scm_cons (scm_from_bool (connect_to_other[LEFT]),
 		 scm_from_bool (connect_to_other[RIGHT]));
-		 
+
   return SCM_EOL;
 }
 
-Grob * 
+Grob *
 Tuplet_bracket::get_common_x (Spanner *me)
 {
   extract_grob_set (me, note-columns, columns);
@@ -282,16 +282,18 @@ Tuplet_bracket::print (SCM smob)
   bool equally_long = false;
   Grob *par_beam = parallel_beam (me, columns, equally_long);
 
-  bool bracket_visibility = !(par_beam  equally_long);
+  bool bracket_visibility = !(par_beam  equally_long);  // Flag, print/don't print tuplet bracket.
   /*
-Fixme: the type of this prop is sucky.
+FIXME: The type of this prop is sucky.
   */
-  SCM bracket = me-get_property (bracket-visibility);
-  if (scm_is_bool (bracket))
-bracket_visibility = ly_scm2bool (bracket);
-  else if (bracket == ly_symbol2scm (if-no-beam))
+  SCM bracket_vis_prop = me-get_property (bracket-visibility);
+  bool bracket_prop = ly_scm2bool (bracket_vis_prop); // Flag, user has set bracket-visibility prop.
+  bool bracket = (bracket_vis_prop == ly_symbol2scm (if-no-beam));
+  if (scm_is_bool (bracket_vis_prop))
+bracket_visibility = bracket_prop;
+  else if (bracket)
 bracket_visibility = !par_beam;
-  
+
   /*
 Don't print a tuplet bracket and number if
 no control-points were calculated
@@ -303,13 +305,17 @@ Tuplet_bracket::print (SCM smob)
   return SCM_EOL;
 }
   /*  if the tuplet does not span any time, i.e. a single-note tuplet, hide
-  the bracket, but still let the number be displayed */
-  if (robust_scm2moment (me-get_bound (LEFT)-get_column ()-get_property (when), Moment (0))
-  == robust_scm2moment (me-get_bound (RIGHT)-get_column ()-get_property (when), Moment (0)))
+  the bracket, but still let the number be displayed.
+  Only do this if the user has not explicitly specified bracket-visibility = #t.
+  */
+  if (!bracket_prop)
   {
-  bracket_visibility = false;
+  if (robust_scm2moment (me-get_bound (LEFT)-get_column ()-get_property (when), Moment (0))
+	  == robust_scm2moment (me-get_bound (RIGHT)-get_column ()-get_property (when), Moment (0)))
+  {
+	  bracket_visibility = false;
+  }
   }
-
   Drul_arrayOffset points;
   points[LEFT] = ly_scm2offset (scm_car (cpoints));
   points[RIGHT] = ly_scm2offset (scm_cadr (cpoints));
@@ -322,7 +328,8 @@ Tuplet_bracket::print (SCM smob)
   Grob *number_grob = unsmob_grob (me-get_object (tuplet-number));
 
   /*
-No bracket when it would be smaller than the number.
+Don't print the bracket when it would be smaller than the number.
+...Unless the user has coded bracket-visibility = #t, that is.
   */
   Real gap = 0.;
   if (bracket_visibility  number_grob)
@@ -332,7 +339,7 @@ Tuplet_bracket::print (SCM smob)
 	{
 	  gap = ext.length () + 1.0;
 
-	  if (0.75 * x_span.length ()  gap)
+	  if ((0.75 * x_span.length ()  gap)  !bracket_prop)
 	bracket_visibility = false;
 	}
 }
@@ -621,7 +628,7 @@ Tuplet_bracket::calc_position_and_height (Grob *me_grob, Real *offset, Real *dy)
   points.push_back (Offset (x0 - x0, staff[dir]));
   points.push_back (Offset (x1 - x0, staff[dir]));
 }
-  
+
   /*
 This is a slight hack. We compute two encompass points from the
 bbox of the smaller tuplets.
@@ -679,7 +686,7 @@