Re: Issue 2177 in lilypond: Patch: Reverts public interface for simple spacer.

[lilypond]

Comment #4 on issue 2177 by lemzw...@gmail.com: Patch: Reverts public  
interface for simple spacer.

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

No, it isn't.  Removing a header file doesn't automatically trigger the  
engine to update the *.dep files.


In groff (which I maintain) I have a `make depend' rule which creates the  
proper dependency files by walking over all C and C++ source code files and  
collecting the output of gcc using the `-MM' switch.  Note, however, that I  
haven't written those rules :-)  Additionally, the whole setup differs too  
much to be of any direct help to lilypond.


Perhaps Julien Rioux could help since he seems to be a makefile guru...



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

Re: Issue 2192 in lilypond: tighter polyphony

[-Eluze]

lilypond-4 wrote:
> 
> Status: Accepted
> Owner: 
> Labels: Type-Enhancement
> 
> New issue 2192 by lemzw...@gmail.com: tighter polyphony
> http://code.google.com/p/lilypond/issues/detail?id=2192
> 
> The attached image shows rather large horizontal distances between the  
> voices (this setup is necessary e.g. for Bach's Chaconne for violin solo,  
> BWV 1004).
> 
> 
> Currently, this horizontal space isn't configurable in lilypond, which I  
> consider a deficiency.
> 
> 
what about

\relative c' <<
  { \voiceOne e'4 }
  \\
  { \voiceThree \override NoteColumn #'force-hshift = #0.25 b4 }
  \\
  { \voiceFive \override NoteColumn #'force-hshift = #0.5 g4 }
  \\
  { \voiceTwo d4 }
>>

http://old.nabble.com/file/p33097464/force-hshift.png 
-- 
View this message in context: 
http://old.nabble.com/Issue-2192-in-lilypond%3A-tighter-polyphony-tp33097351p33097464.html
Sent from the Gnu - Lilypond - Bugs mailing list archive at Nabble.com.


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

Re: Issue 2134 in lilypond: Redirect old website / download to new location

[lilypond]

Comment #4 on issue 2134 by gra...@percival-music.ca: Redirect old website  
/ download to new location

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

something along the above patch may be used eventually, but I guess you  
could consider this issue as being blocked on other work.


I think the next stage of that "other work" is to handle the translations  
stuff.  Make an html/ directory, just like the pdf/ directory, copy the  
relevant translation file(s) into there, and add it to website.make just  
like the pdf stuff.


We don't have an RSS feed, so ignore that one.

After that's done, let me know what links (if any) are still in old news.   
I think we'll just ignore them, but we should probably at least take a  
quick glance at them.



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

Issue 2193 in lilypond: collision between beams and rests

[lilypond]

Status: Accepted
Owner: 

New issue 2193 by lemzw...@gmail.com: collision between beams and rests
http://code.google.com/p/lilypond/issues/detail?id=2193

\version "2.15.24"

\header { texidoc = "
Bars and rests from different voices shouldn't collide.

Here is a counterexample, which is a regression compared to version 2.14.1.
" }

\relative c' <<
  { \voiceOne c'8 r } \\
  { \voiceThree c,8.[ c'16] }



Attachments:
beam-rest-collision.png  5.7 KB
beam-rest-collision-2.14.1.png  14.0 KB


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

Re: Issue 2177 in lilypond: Patch: Reverts public interface for simple spacer.

[lilypond]

Comment #3 on issue 2177 by gra...@percival-music.ca: Patch: Reverts public  
interface for simple spacer.

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

how on earth do I do that?

I suspected a build problem, so patchy now re-runs autogen.sh and  
configure.  That isn't enough to regenerate all *.dep files?!



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

Issue 2192 in lilypond: tighter polyphony

[lilypond]

Status: Accepted
Owner: 
Labels: Type-Enhancement

New issue 2192 by lemzw...@gmail.com: tighter polyphony
http://code.google.com/p/lilypond/issues/detail?id=2192

The attached image shows rather large horizontal distances between the  
voices (this setup is necessary e.g. for Bach's Chaconne for violin solo,  
BWV 1004).


\version "2.15.24"

voiceFive = #(context-spec-music (make-voice-props-set 4) 'Voice)

\relative c' <<
  { \voiceOne e'4 } \\
  { \voiceThree b4 } \\
  { \voiceFive g4 } \\
  { \voiceTwo d4 }


The Bärenreiter Urtext edition uses half the horizontal distances or even  
less.


Currently, this horizontal space isn't configurable in lilypond, which I  
consider a deficiency.



Attachments:
polyphony.png  1.5 KB

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

Re: Issue 2177 in lilypond: Patch: Reverts public interface for simple spacer.

[lilypond]

Comment #2 on issue 2177 by lemzw...@gmail.com: Patch: Reverts public  
interface for simple spacer.

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

This is a problem with patchy: After applying a patch, all *.dep files
should be regenerated.  The patch itself works fine, BTW, at least on
my machine.



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

Issue 2191 in lilypond: Web: update to version 2.15, use it in the "site:" part

[lilypond]

Status: Started
Owner: pkx1...@gmail.com
Labels: Type-Enhancement Patch-new

New issue 2191 by pkx1...@gmail.com: Web: update to version 2.15, use it in  
the "site:" part

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

Patch from

Pavel Roskin

Doc search: update to version 2.15, use it in the "site:" part

site:lilypond.org/doc/v2.15 means that we want to look only under that
directory.  Leading plus doesn't force the exact search anymore.

---

Note: I wasn't sure if this was for any specific existing tracker issue or  
not so created a new one.


http://codereview.appspot.com/5530043/




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

Re: Issue 2134 in lilypond: Redirect old website / download to new location

[lilypond]

Comment #3 on issue 2134 by pkx1...@gmail.com: Redirect old website /  
download to new location

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

Graham/Alberto I'm not sure about this issue now, I see the tracker has  
been 'closed' after Alberto's last 'comment' in  
http://codereview.appspot.com/5500069/ which was after Grahams last update  
in this tracker issue.


Is there a patch that needs work or is there no longer any patch and this  
is just a regular tracker issue again?


James


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

Re: Issue 1943 in lilypond: lilypond after 2.15.8 fails on x86 Macs

[lilypond]

Comment #26 on issue 1943 by c_soren...@byu.edu: lilypond after 2.15.8  
fails on x86 Macs

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

Christian,

What did you to to make these run?  I'd like to get the appropriate  
commands in GUB so that the OS/X releases work properly.


Thanks,

Carl



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

Re: Issue 2177 in lilypond: Patch: Reverts public interface for simple spacer.

[lilypond]

Updates:
Labels: Patch-needs_work

Comment #1 on issue 2177 by lilypond...@gmail.com: Patch: Reverts public  
interface for simple spacer.

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

Patchy the autobot says: no rule to make column-description.hh needed by  
simple-spacer



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

Re: Issue 2189 in lilypond: Doc: NR add to \partial for clearer understanding

[lilypond]

Updates:
Labels: Patch-review

Comment #3 on issue 2189 by lilypond...@gmail.com: Doc: NR add to  \partial  
for clearer understanding

http://code.google.com/p/lilypond/issues/detail?id=2189#c3

Patchy the autobot says: LGTM.


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

Re: Issue 2188 in lilypond: Patch: Turns beam translation into a callback.

[lilypond]

Updates:
Labels: Patch-needs_work

Comment #4 on issue 2188 by lilypond...@gmail.com: Patch: Turns beam  
translation into a callback.

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

Patchy the autobot says: tons of warnings and stem-tremolo-staff-space.ly  
looks silly



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

Re: Issue 2149 in lilypond: Patch: Creates non-negative-integer? predicate.

[lilypond]

Comment #22 on issue 2149 by plros...@gmail.com: Patch: Creates  
non-negative-integer? predicate.

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

\bikeshedOn

In my experience, negation is a distraction for human mind.  As a C  
programmer, I strive to use "HAVE_FOO" rather than "HAVE_NO_FOO", even  
when "HAVE_FOO" would be defined almost always.  It's more important to  
spare fellow programmers a few some logical operations in their minds than  
to minimize the amount of defines for the compiler.  It is human minds make  
things work or break, and they should not be loaded with things computers  
do better, such as interpreting "#ifndef HAVE_NO_FOO".  Therefore,  
any "non-x" is a non-starter in my opinion.


"unsigned-integer" or "unsigned" would be fine if Lilypond were a  
development tool, as "un" in "unsigned" is not really normally thought of  
as a negation, but more as a forced plus sign and and extra bit.


Since Lilypond is not (only) for programmers, "natural-integer" seems a  
better choice.  Even musicians study natural numbers in school.  I know  
that not everybody considers 0 a natural number, but Lilypond can be a bit  
sloppy here.  Mathematicians will excuse us.  On the other hand,  
simply "natural" would be confusing for some musicians, as it's an  
accidental name.


Therefore I believe that the "natural-integer?" predicate would be the best  
choice.



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

Re: Issue 586 in lilypond: Cross-staff slur causes a weird output

[lilypond]

Comment #12 on issue 586 by plros...@gmail.com: Cross-staff slur causes a  
weird output

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

I don't think there is any bug that puts the slur start on the wrong  
staff.  Try adding this:

#(set-global-staff-size 20)

Now change the number gradually to 19.5, 19, 18.5.  You'll see how the slur  
start goes down gradually until it approaches the notehead.  There is no  
jump from one staff to another.


Also, the first tuplet could look better.  This is discussed in the issue  
2190.



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

Re: Issue 1933 in lilypond: Lilypond-book requires msvcrt again

[m...@apollinemike.com]

On Jan 6, 2012, at 10:49 PM, Trevor Daniels wrote:

> 
>> Comment #13 on issue 1933 by m...@apollinemike.com: Lilypond-book requires
>> msvcrt again
>> http://code.google.com/p/lilypond/issues/detail?id=1933
>> 
>> I think I may have found a one-stop-shopping solution to most of these 
>> problems:
>> 
>> http://python-mingw.donbennett.org:8081/mywiki/Installation
> 
> Mike
> 
> This seems to use a version of subprocess.py which works only under MinGW, 
> not in Windows command box.  And msvcrt seems not to be included anyway. Why 
> do you think this will solve the problem?
> 

Ah, ok, sorry.  I didn't understand that.  I had read the testimonials and it 
compiled clean, so I figured it was worth a try.
Back to the drawing board...

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

Re: Issue 1933 in lilypond: Lilypond-book requires msvcrt again

[Trevor Daniels]

Comment #13 on issue 1933 by m...@apollinemike.com: Lilypond-book requires
msvcrt again
http://code.google.com/p/lilypond/issues/detail?id=1933

I think I may have found a one-stop-shopping solution to most of these 
problems:


http://python-mingw.donbennett.org:8081/mywiki/Installation


Mike

This seems to use a version of subprocess.py which works only under MinGW, 
not in Windows command box.  And msvcrt seems not to be included anyway. 
Why do you think this will solve the problem?


Trevor


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

Re: Issue 1933 in lilypond: Lilypond-book requires msvcrt again

[lilypond]

Comment #13 on issue 1933 by m...@apollinemike.com: Lilypond-book requires  
msvcrt again

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

I think I may have found a one-stop-shopping solution to most of these  
problems:


http://python-mingw.donbennett.org:8081/mywiki/Installation

It is a series of patches to Python 2.5 that builds a stable version using  
mingw.
I built it and it seems stable.  The build instructions are easy.  All I  
cannot figure out is incorporate it into GUB.  Graham - would you know how  
to patch GUB so that it builds python using this tool and then makes this  
the python that ships with windows?



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

Re: Tuplet positioning on beamed notes is ugly

[Marek Klein]

2012/1/1 Chris Morgan 

> On Sun, Jan 1, 2012 at 1:01 AM, James  wrote:
>
> > > \markup { Here is how beamed quaver tuplets look now; ugly, with some
> > colliding
> > > with the staff lines: }
>

This has been added as
http://code.google.com/p/lilypond/issues/detail?id=2190
Thank you for report.

Marek Klein,
bug squad
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Issue 2190 in lilypond: Tuplet positioning on beamed notes is ugly

[lilypond]

Status: Accepted
Owner: 
Labels: Type-Ugly

New issue 2190 by ma...@gregoriana.sk: Tuplet positioning on beamed notes  
is ugly

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

http://lists.gnu.org/archive/html/bug-lilypond/2011-12/msg01116.html
\version "2.15.23" % also 2.14.2

\markup { Here is how beamed quaver tuplets look now; ugly, with some  
colliding

with the staff lines: }
\relative f' {
 \times 2/3 { f8 f f }
 \times 2/3 { e e e }
 \times 2/3 { d d d }
 \times 2/3 { c c c } % All lower notes are the same as this;
 \times 2/3 { b b b } % the beam will go no lower
 \override TupletBracket #'bracket-visibility = ##t
 \times 2/3 { f' f f }
 \times 2/3 { e e e }
 \times 2/3 { d d d }
 \times 2/3 { c c c }
 \times 2/3 { b b b }
}

\markup { Here is somewhat more how they should look (dodging the staff  
lines): }

\relative f' {
 \times 2/3 { f8 f f }
 \tweak #'padding #1.80 \times 2/3 { e e e }
 \tweak #'padding #1.95 \times 2/3 { d d d }
 % Well, actually, I'm not convinced about these last two.
 \tweak #'padding #2.75 \times 2/3 { c c c }
 \tweak #'padding #2.75 \times 2/3 { b b b }
 \override TupletBracket #'bracket-visibility = ##t
 \times 2/3 { f' f f }
 \tweak #'padding #1.95 \times 2/3 { e e e }
 \tweak #'padding #2.10 \times 2/3 { d d d }
 \tweak #'padding #2.90 \times 2/3 { c c c }
 \tweak #'padding #2.90 \times 2/3 { b b b }
}

\markup \column {
 \line { Where there is no beam (e.g. crochets, "\autoBeamOff"), this issue
doesn't appear at all. }
 \line { (Though the number alone with no TupletBracket is, in my opinion,  
too

high.) }
}
\relative f' {
 \autoBeamOff
 \override TupletBracket #'bracket-visibility = ##f
 \times 2/3 { f8 f f }
 \times 2/3 { e e e }
 \times 2/3 { d d d }
 \times 2/3 { c c c }
 \times 2/3 { b b b }
 \override TupletBracket #'bracket-visibility = ##t
 \times 2/3 { f' f f }
 \times 2/3 { e e e }
 \times 2/3 { d d d }
 \times 2/3 { c c c }
 \times 2/3 { b b b }
}

Attachments:
bug.png  33.6 KB


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

Re: Issue 1948 in lilypond: Windows install clobbered system PATH

[lilypond]

Comment #30 on issue 1948 by m...@apollinemike.com: Windows install  
clobbered system PATH

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

mingw .exe will be uploaded in about 5 minutes.


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

Re: Issue 2189 in lilypond: Doc: NR add to \partial for clearer understanding

[lilypond]

Updates:
Labels: Patch-new

Comment #2 on issue 2189 by pkx1...@gmail.com: Doc: NR add to  \partial for  
clearer understanding

http://code.google.com/p/lilypond/issues/detail?id=2189#c2

Doc: NR Section on Upbeats made clearer

Tracker issue 2189

Created simpler and clearer @lilypond examples.

Used a less complex, more obvious value for \set Timing.measure position
examples and added a specific example after the @knownissue to show
\partial and \set Timing.. being used together (at the beginning and
after the beginning) to help reinforce the point.

Minor cindex changes and linebreak edits as per the CG

http://codereview.appspot.com/5520056


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

Re: Issue 2189 in lilypond: Doc: NR add to \partial for clearer understanding

[lilypond]

Comment #1 on issue 2189 by d...@gnu.org: Doc: NR add to  \partial for  
clearer understanding

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

I don't think the wording is significantly clearer.  It is a good idea to  
avoid "interval" since that has a different meaning in music, but I'd  
keep "remaining", as "gives the remaining length of the partial measure".


But of course, the real help is the example.


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

Re: Issue 1948 in lilypond: Windows install clobbered system PATH

[lilypond]

Updates:
Labels: Patch-new

Comment #29 on issue 1948 by pkx1...@gmail.com: Windows install clobbered  
system PATH

http://code.google.com/p/lilypond/issues/detail?id=1948#c29

Doc: Usage - added link for Windows users

This is part of Tracker 1948

The Document now links to the installation instructions to Windows
As it did for MacOS X in order to show users how to manually
edit their PATH statement for Windows.

Also updated some of the 'nearby' CINDEX entries in the file

http://codereview.appspot.com/5521056


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

Re: Issue 2187 in lilypond: git-cl doesn't 'always' remember (the last) tracker issue number you used

[lilypond]

Updates:
	Summary: git-cl doesn't 'always' remember (the last) tracker issue number  
you used

Labels: -Type-Git-cl Type-Scripts git-cl

Comment #1 on issue 2187 by pkx1...@gmail.com: git-cl doesn't 'always'  
remember (the last) tracker issue number you used

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

(No comment was entered for this change.)


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

Issue 2189 in lilypond: Doc: NR add to \partial for clearer understanding

[lilypond]

Status: Accepted
Owner: 
Labels: Type-Documentation

New issue 2189 by pkx1...@gmail.com: Doc: NR add to  \partial for clearer  
understanding

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

Laura Conrad lcon...@laymusic.org via gnu.org




to lilypond-user

"David" == David Kastrup  writes:


   >> From the manual:

http://lilypond.org/doc/v2.14/Documentation/notation-big-page.html#upbeats

   David> Upbeats
   David> ...

   David> Partial or pick-up measures, such as an anacrusis or upbeat,  
are

   David> entered using the `\partial' command, with the syntax

   David> \partial DURATION

   David> where `DURATION' is the rhythmic length of the remaining  
interval of

   David> the current measure before the start of the next.

   David> I repeat: the length of the _remaining_ interval of the current
   David> measure.  So you need \partial 2 here.

Yes, I've read that section regularly for the last 15 years or so, and
obviously never understood it. I've occasionally managed to get an
anacrusis entered correctly, but since I don't usually use barlines, I
haven't always been able to tell whether Lily understood what I was
saying or not.

I always thought that if I ever did figure out what it meant, I should
help rewrite it.

How about:

   \partial DURATION

   where 'DURATION' describes the length of the partial measure.  For
   example:

   \time 4/4
   \partial 4
   g4 | c c c2 |

I think including an example in a case like this is always a good idea.



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

Re: Issue 1948 in lilypond: Windows install clobbered system PATH

[lilypond]

Comment #28 on issue 1948 by m...@apollinemike.com: Windows install  
clobbered system PATH

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

On it.


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

Re: Issue 1948 in lilypond: Windows install clobbered system PATH

[lilypond]

Comment #27 on issue 1948 by philehol...@gmail.com: Windows install  
clobbered system PATH

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

As promised, a patch for GUB.  Could someone who has this working download  
and apply this, please?  The outcome should be that PATH is unchanged  
either with an install or uninstall.  This is best checked using the Method  
described above via Control Panel, rather than a command window, which  
unreliably updates based on changes to the registry.


Attachments:
0001-Stops-Windows-PATH-being-changed.patch  2.1 KB


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

Re: Issue 1948 in lilypond: Windows install clobbered system PATH

[lilypond]

Comment #26 on issue 1948 by philehol...@gmail.com: Windows install  
clobbered system PATH

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

I'll make a GUB patch and post it here.

James added this to the discussion:

"If you look here:

http://lilypond.org/doc/v2.14/Documentation/usage/lilypond_002dbook

It links to Command Line Usage  which says if you use mac then you
need to go here

http://lilypond.org/doc/v2.14/Documentation/web/macos-x

and so we can make a similar entry in Usage and point them to

http://lilypond.org/doc/v2.14/Documentation/web/windows

! which is what we've had all along - we just never linked to it from
Usage like we do Mac OS X.

Voila!

I can do that.

Just let me know if that is the route we are going down now."

I also believe  
http://lilypond.org/doc/v2.14/Documentation/learning/command_002dline needs  
checking and updating.


I'd suggest telling users how to modify their PATH by using Control Panel;  
System; Advanced (XP - or "Advanced System Settings" for Vista - probably  
the same for W7, if someone can check); Environment Variables; System  
Variables; Edit PATH.  Then add ;C:\Program Files\LilyPond\usr\bin and OK.


I'd really appreciate it if you could pick this aspect up, James.


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

Re: Issue 2188 in lilypond: Patch: Turns beam translation into a callback.

[lilypond]

Comment #3 on issue 2188 by lemzw...@gmail.com: Patch: Turns beam  
translation into a callback.

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

beam-distance?


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

Re: Issue 2188 in lilypond: Patch: Turns beam translation into a callback.

[lilypond]

Comment #2 on issue 2188 by m...@apollinemike.com: Patch: Turns beam  
translation into a callback.

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

I agree - what would you suggest renaming it?


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

Re: Issue 2188 in lilypond: Patch: Turns beam translation into a callback.

[lilypond]

Comment #1 on issue 2188 by lemzw...@gmail.com: Patch: Turns beam  
translation into a callback.

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

LGTM.  In this context I strongly suggest to better document (or even  
rename) `length-fraction'.




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

Issue 2188 in lilypond: Patch: Turns beam translation into a callback.

[lilypond]

Status: New
Owner: 
Labels: Type-Enhancement Patch-new

New issue 2188 by mts...@gmail.com: Patch: Turns beam translation into a  
callback.

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

Turns beam translation into a callback.

http://codereview.appspot.com/5517055


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

Re: Issue 2149 in lilypond: Patch: Creates non-negative-integer? predicate.

[lilypond]

Comment #21 on issue 2149 by d...@gnu.org: Patch: Creates  
non-negative-integer? predicate.

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

I have turned to the Guile manual for guidance about what would fit into  
the scheme of names, and we have basically "length" as a textual  
description for things like vector sizes or "index" for addressing them.


Guile actually has no problems creating a vector of length 0.  "length" in  
LilyPond is likely not a good idea since it suggests metric lengths, and  
also does not obviously include 0.  index? is not all that optimal since  
using it for the size rather than the index of an array is a bit strained  
(it's basically the index beyond the array).  However, it seems less  
strained than using "count?" as an index type since one does not really  
_count_ the values processed so far.


And I think it will usually correspond rather closely to what we would be  
using it for.


Barring protests in the next few days, I'll check in a version using index?  
instead.  I think that it should, for most of our purposes, be more natural  
than non-negative-integer?.  For a similar reason, I had created a  
predicate fraction? rather than non-negative-integer-pair?.  It does not  
capture all possible uses of this predicate, but for the real existing  
uses, being totally exact would be much more cumbersome.



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

Issue 2187 in lilypond: git-cl doesn't remember tracker issue number

[lilypond]

Status: Accepted
Owner: 
Labels: Type-Git-cl

New issue 2187 by janek.li...@gmail.com: git-cl doesn't remember tracker  
issue number

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

If you tell git-cl to create a new tracker issue when uploading, it doesn't  
remember the number of created issue (and you have to tell it again every  
time you upload new version of patch).


It would be nice to store this number, just like rietveld issue number is  
stored in .git/config .



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

Issue 2186 in lilypond: git-cl always uses first commit's message

[lilypond]

Status: Accepted
Owner: 
Labels: Type-Git-cl

New issue 2186 by janek.li...@gmail.com: git-cl always uses first commit's  
message

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

You wrote a patch, committed it and uploaded with git-cl - everything is  
fine, commit message is displayed in tracker issue.  Now make some changes  
to the patch, commit them and use git-cl again - it will add a comment to  
the tracker issue containing first commit message, not the message from the  
new commit.



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

Re: Issue 1948 in lilypond: Windows install clobbered system PATH

[lilypond]

Comment #25 on issue 1948 by m...@apollinemike.com: Windows install  
clobbered system PATH

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

I think that Phil's proposal is the best option - please make the patch.


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

Re: Issue 2184 in lilypond: GUB can't download netpbm

[lilypond]

Comment #1 on issue 2184 by gra...@percival-music.ca: GUB can't download  
netpbm

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

also necessary for
  bin/gub tools::rsync


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

Re: Chord fingering placement bug?

[Ralph Palmer]

On Wed, Jan 4, 2012 at 7:09 PM, Nick Payne wrote:

> On 05/01/12 07:58, Nick Payne wrote:
>
>> See below. If the note with the accidental appears first in the chord,
>> then the fingering for the other note correctly avoids the accidental. If
>> the order of the notes is reversed, the fingering collides with the
>> accidental. I don't know if this is related to issue 1222 (
>> http://code.google.com/p/**lilypond/issues/detail?id=1222
>> **), also concerning fingering colliding with an accidental.
>>
>> \version "2.15.23"
>>
>> \relative c'' {
>>\set fingeringOrientations = #'(left)
>> 1
>> 
>> }
>>
>
> p.s. I also think that Lilypond's default spacing places fingering is too
> far away from the note. It looks better, and is less confusing (see also
> issue 220) with the following overrides:
>
> \relative c'' {
>\set fingeringOrientations = #'(left)
> 1
>\override Fingering #'padding = #0.3
>\override Staff.AccidentalPlacement #'left-padding = #0
> 
> }
>

Greetings Nick and list members. This has been submitted as issue 2185 :
http://code.google.com/p/lilypond/issues/detail?id=2185

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

Issue 2185 in lilypond: Chord fingering placement request

[lilypond]

Status: Accepted
Owner: 
Labels: Type-Ugly

New issue 2185 by ralphbug...@gmail.com: Chord fingering placement request
http://code.google.com/p/lilypond/issues/detail?id=2185

This is more of an aesthetic question than a bug. Do we need further  
discussion?


Nick Payne wrote :
I also think that Lilypond's default spacing places fingering is too far  
away from the note. It looks better, and is less confusing (see also issue  
220) with the following overrides:


\relative c'' {
   \set fingeringOrientations = #'(left)
1
   \override Fingering #'padding = #0.3
   \override Staff.AccidentalPlacement #'left-padding = #0

}



Attachments:
test.preview(1).png  2.2 KB


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

Issue 2184 in lilypond: GUB can't download netpbm

[lilypond]

Status: Accepted
Owner: 
Labels: Type-Critical

New issue 2184 by gra...@percival-music.ca: GUB can't download netpbm
http://code.google.com/p/lilypond/issues/detail?id=2184

the existing url is broken, which I'm going to fix in a minute or two.  But  
even with the right url, GUB doesn't automatically download netpbm when  
it's needed as part of make doc.  It realizes that it needs to (re)build  
netpbm, but it always skips over the download stage and attempts to do the  
untar stage.  Since it's never downloaded netpbm in the first place, the  
untar dies.


Solution: manually trigger a full netpbm installation with
  bin/gub tools::netpbm


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

Re: Issue 1948 in lilypond: Windows install clobbered system PATH

[James]

hello,

On 6 January 2012 11:23,   wrote:
> On Fri, 6 Jan 2012 11:14:34 +, Graham Percival wrote:
>>
>> On Fri, Jan 06, 2012 at 10:21:19AM +, lilyp...@googlecode.com wrote:
>>>
>>>
>>> We'd need to be careful over that.  Think it's no problem from a
>>> pure Lilypond perspective - I'd doubt many windows users would run
>>> lily from the command line.  However, I believe they would run -book
>>> from the command line, and that needs to find the python module in
>>> the path statement, I think.
>>
>>
>> Good point!  Does anybody feel like checking into this?
>>
>> I still think it's best to just explain which directories need to
>> be in the PATH rather than modifying it ourselves, but we'll need
>> to know this information when it comes time to write that
>> documentation.
>>
>> Cheers,
>> - Graham
>
>
> I think that all you need is:
>
> PATH_TO_LILYPOND\usr\bin
>
> In most set-ups this'd be:
>
> C:\Program Files\LilyPond\usr\bin
>
> Cheers,
> MS
>

Yes this is the default. The installer lets you choose the location,
but Windows' users will be used to the 'C:\Program
Files\LilyPond\usr\bin' nomenclature.

I'd say 99% of all users will use the default path, and those that
choose to move it will know that they need to adjust their PATH
accordingly.

If you look here:

http://lilypond.org/doc/v2.14/Documentation/usage/lilypond_002dbook

It links to Command Line Usage  which says if you use mac then you
need to go here

http://lilypond.org/doc/v2.14/Documentation/web/macos-x

and so we can make a similar entry in Usage and point them to

http://lilypond.org/doc/v2.14/Documentation/web/windows

! which is what we've had all along - we just never linked to it from
Usage like we do Mac OS X.

Voila!

I can do that.

Just let me know if that is the route we are going down now.


-- 
--

James

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

Re: Issue 1948 in lilypond: Windows install clobbered system PATH

[lilypond]

Comment #24 on issue 1948 by philehol...@gmail.com: Windows install  
clobbered system PATH

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

Graham said:

Good point!  Does anybody feel like checking into this?

I still think it's best to just explain which directories need to
be in the PATH rather than modifying it ourselves, but we'll need
to know this information when it comes time to write that
documentation.

and Mike added:

I think that all you need is:

PATH_TO_LILYPOND\usr\bin

In most set-ups this'd be:

C:\Program Files\LilyPond\usr\bin

If we agree that the best option is to stop the lilypond install attempting  
to edit the path statement at all, and that we then add a bit to usage and  
learning to tell people how to modify their path if they want, then I can  
make those changes.  The manuals is no problem.  I think for the NSIS stuff  
I can make the changes but would need to supply a patch to be added to GUB.



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

Re: Issue 2171 in lilypond: Patch: Implements DOM-id property for grobs.

[lilypond]

Comment #11 on issue 2171 by m...@apollinemike.com: Patch: Implements  
DOM-id property for grobs.

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

But I don't agree with your assessment that there was no reason to holler  
in the first place.


I'm sorry if I gave this impression - I certainly welcome any and all  
comments on the patch.  The Reitveld issue is still up, so you can suggest  
a reformulated doc-string through that & I'll incorporate it into a future  
patch.



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

Re: Issue 2171 in lilypond: Patch: Implements DOM-id property for grobs.

[lilypond]

Comment #10 on issue 2171 by d...@gnu.org: Patch: Implements DOM-id  
property for grobs.

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

Mike: again, I am not proud of my performance here.  But where is the point  
of a review where the issue, the review description, and the code contain  
not a single word about what problem they intend to address?  Where is the  
point in adding a user (or application programmer) feature without a  
regtest and without any documentation?


No, I don't consider "The ID of a DOM node in an XML document." on a  
property sufficient documentation.  There is not a single comment in the  
whole commit, anything that would even tell somebody reading the code what  
this is supposed to do and how,  The only piece of documentation is the  
quoted string above.


I don't see how this is anything but dead code and a maintenance burden for  
anybody but the original author.  Yes, I should have hollered the moment it  
started "review" (how do you review an issue without any more information  
than the issue title?).


And it is entirely my fault that I did not holler, and it is an aggravating  
way in which I try fixing it after the last minute.


But I don't agree with your assessment that there was no reason to holler  
in the first place.



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

Re: Issue 1948 in lilypond: Windows install clobbered system PATH

[mike]

On Fri, 6 Jan 2012 11:14:34 +, Graham Percival wrote:
On Fri, Jan 06, 2012 at 10:21:19AM +, lilyp...@googlecode.com 
wrote:


We'd need to be careful over that.  Think it's no problem from a
pure Lilypond perspective - I'd doubt many windows users would run
lily from the command line.  However, I believe they would run -book
from the command line, and that needs to find the python module in
the path statement, I think.


Good point!  Does anybody feel like checking into this?

I still think it's best to just explain which directories need to
be in the PATH rather than modifying it ourselves, but we'll need
to know this information when it comes time to write that
documentation.

Cheers,
- Graham


I think that all you need is:

PATH_TO_LILYPOND\usr\bin

In most set-ups this'd be:

C:\Program Files\LilyPond\usr\bin

Cheers,
MS

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

Re: Issue 1948 in lilypond: Windows install clobbered system PATH

[Graham Percival]

On Fri, Jan 06, 2012 at 10:21:19AM +, lilyp...@googlecode.com wrote:
> 
> We'd need to be careful over that.  Think it's no problem from a
> pure Lilypond perspective - I'd doubt many windows users would run
> lily from the command line.  However, I believe they would run -book
> from the command line, and that needs to find the python module in
> the path statement, I think.

Good point!  Does anybody feel like checking into this?

I still think it's best to just explain which directories need to
be in the PATH rather than modifying it ourselves, but we'll need
to know this information when it comes time to write that
documentation.

Cheers,
- Graham

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

Re: Issue 1948 in lilypond: Windows install clobbered system PATH

[lilypond]

Comment #23 on issue 1948 by pkx1...@gmail.com: Windows install clobbered  
system PATH

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

Suggest adding something in the Usage Manual then. Normally users would  
look in usage for Lilypond-book right?



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

Re: Issue 2171 in lilypond: Patch: Implements DOM-id property for grobs.

[lilypond]

Comment #9 on issue 2171 by m...@apollinemike.com: Patch: Implements DOM-id  
property for grobs.

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

If people would not consider it totally fine to just ignore every  
standard we set up, I would not be appalled to a degree where I act in  
that manner.


I do not feel that I act this way.

There are new stencil commands "start-enclosing-DOM-mode",  
and "end-enclosing-DOM-node".  Those are entirely undocumented.


Do a git grep on:

resetcolor
setcolor
no-origin
url-link

Aside from additions to the change-log attesting that these functions were  
added, there is no documentation for them.  That is because they are  
internal stencil functions that users will never see but are used to pass  
around information.


If you want to bring up the issue that all stencils should be documented  
and/or user accessible that is fine.  But when you say "those are entirely  
undocumented", I get the impression that you feel that documenting this  
sort of stencil falls into the "every standard se set up" category, which  
is not the case.


As for usability, I agree that undocumented features are bad.  As James can  
attest, I often contact him after I've added a feature to start working on  
documentation.  However, as it stands, the documentation of this feature is  
no less or more than other documentation for similar features.  And if you  
have a problem with the doc string, then that is an easy separate commit I  
can make later down the line rather than going through the time drain fo a  
revert.


I agree with you that it is bad for LilyPond to become more  
underdocumented, but I disagree that it is an undocumented mess.  I think  
that the documentation in LilyPond is some of the best (if not the best) of  
any project of its kind, and I think that as long as people make an honest  
effort to work with James to improve the documentation around new features,  
it will continue to achieve that comparatively hight standard.


What I'm asking is for you to please be aware that the way you communicate  
has a real impact on how people spend their time, be it in e-mail exchanges  
or in the reverting of patches.  It has this impact because you're very  
good at what you do, so I take it seriously.  This is not unlike a long  
conversation we had a few weeks ago where you made several assertions about  
a patch I wrote that proved be false, causing me to do a great deal of  
research because I trusted that they were assertions and not questions,  
only to read at the end of the exchange "Well, it is good we had this  
little talk then.  Be sure to keep this reasonably discoverable in the  
program documentation, and you'll be pretty safe from future  
keyword-triggered watchdog attacks."  I very much appreciate the rigor with  
which you police LilyPond and think it is necessary for the program.  If  
you could formulate that policing in the form of questions instead of  
assertions and not let it result in reverting patches, it would save me  
lots of time and allow me get better at making LilyPond better.



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

Re: Issue 1948 in lilypond: Windows install clobbered system PATH

[lilypond]

Comment #22 on issue 1948 by philehol...@gmail.com: Windows install  
clobbered system PATH

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

We'd need to be careful over that.  Think it's no problem from a pure  
Lilypond perspective - I'd doubt many windows users would run lily from the  
command line.  However, I believe they would run -book from the command  
line, and that needs to find the python module in the path statement, I  
think.



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

Re: Issue 2171 in lilypond: Patch: Implements DOM-id property for grobs.

[lilypond]

Comment #8 on issue 2171 by d...@gnu.org: Patch: Implements DOM-id property  
for grobs.

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

I don't think it's good practice to unilaterally bounce patches from  
staging based on one's personal opinion of the quality of the patch.


No, it isn't, but I can't keep up with reviewing everything in a single day  
that all contributors keep throwing at LilyPond.  It is also not good  
practice to ignore _all_ standards of coding.  If people would not consider  
it totally fine to just ignore every standard we set up, I would not be  
appalled to a degree where I act in that manner.


The "documentation" of the whole patch, the "doc-string of the property",  
is:

+ (DOM-id ,string? "The ID of a DOM node in an XML document.")

There is no other documentation.  There are new stencil  
commands "start-enclosing-DOM-mode", and "end-enclosing-DOM-node".  Those  
are entirely undocumented.


The commit message gives a tiny bit of information but has not been part of  
the review and is not part of the work tree.


How is _anybody_ supposed to work with that?  It is supposed to be a usable  
feature, isn't it?


Yes, I agree it is bad style to take things from staging after they have  
passed a countdown.  And I wish I would have been faster, and that I would  
be omnipresent in all reviews.  It is much more of a hassle for me as well  
to fix things after the fact.  Things move from staging to master fast.


I _hate_ meddling with those processes and stop the printing presses so to  
say.  But I hate seeing become LilyPond become more of an underdocumented  
mess than it already is.



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

Re: Issue 2175 in lilypond: Patch: explain how to add git-cl to PATH

[lilypond]

Comment #2 on issue 2175 by janek.li...@gmail.com: Patch: explain how to  
add git-cl to PATH

http://code.google.com/p/lilypond/issues/detail?id=2175#c2

explain how to add git-cl to PATH

i know modifying PATH is basic knowledge,
but i'm windows man and figuring this out
took me 15 minutes... too long.

http://codereview.appspot.com/5503093


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

Re: Issue 1629 in lilypond: Tuplet line collides with fingering

[lilypond]

Updates:
Status: Fixed

Comment #6 on issue 1629 by mts...@gmail.com: Tuplet line collides with  
fingering

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

Pushed to staging as 929c7dbb51877dc11825a13e8a25456b2b14532a.


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

Re: Issue 2171 in lilypond: Patch: Implements DOM-id property for grobs.

[Graham Percival]

On Fri, Jan 06, 2012 at 09:37:51AM +, lilyp...@googlecode.com wrote:
> 
> I don't think it's good practice to unilaterally bounce patches from
> staging based on one's personal opinion of the quality of the patch,
> especially when the patch has had a human LGTM from the best SVG
> developer on the team.

+1

I would be delighted to see more questions, comments, or even
arguments, during the countdown phase.  But once it's gone through
the countdown, the only reason patches should be bounced is if
they fail the objective tests in Patchy (i.e. able to complete
make, make test, and make doc).

Cheers,
- Graham

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

Re: Issue 2171 in lilypond: Patch: Implements DOM-id property for grobs.

[lilypond]

Comment #7 on issue 2171 by m...@apollinemike.com: Patch: Implements DOM-id  
property for grobs.

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

I don't think it's good practice to unilaterally bounce patches from  
staging based on one's personal opinion of the quality of the patch,  
especially when the patch has had a human LGTM from the best SVG developer  
on the team.


The patch has documentation (the doc-string of the property) that describes  
what it does and currently lilypond has no regtests for the svg backend - I  
don't even know what these regtests would look like or how this property  
would/could be tested aside from just setting it (it doesn't have any  
influence in postscript files).  I was about to e-mail James to talk to him  
about writing up some documentation about backend-divergent properties  
(like embedded-ps, which also doesn't have a regtest).


The purpose of the patch was written in the commit message.

I have lost 20 minutes writing this message in addition to the time spent  
trying to figure out what was wrong with my repo before I saw your message  
about reverting the patch, and I will lose time re-preparing and re-pushing  
this after it goes through a review cycle.  Of course, when talking about  
lost time, it is important not to forget the time that other developers  
invariably lose cleaning up after someone's bad work, and I understand that  
this was your reason for reverting the patch.  But I do not believe this to  
be bad work and I think that, as a community, all of us should avoid making  
unilateral decisions with respect to staging.



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

Re: Issue 2171 in lilypond: Patch: Implements DOM-id property for grobs.

[lilypond]

Updates:
Status: Started

Comment #6 on issue 2171 by d...@gnu.org: Patch: Implements DOM-id property  
for grobs.

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

(No comment was entered for this change.)


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

Re: Issue 2171 in lilypond: Patch: Implements DOM-id property for grobs.

[lilypond]

Updates:
Labels: -Patch-push Patch-review

Comment #5 on issue 2171 by d...@gnu.org: Patch: Implements DOM-id property  
for grobs.

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

WTF is this even for?  There is no explanation whatsoever in the issue  
description, there is no explanation in the review, there is no explanation  
in the code and no documentation and no regtest.


Yes, I overlooked this in the review process, probably since it did not  
even contain a single sentence pointing out what this is, but I am taking  
the liberty of backing this patch out of staging and setting it back to  
review.  Without any discoverable purpose and regtest and description and  
documentation, this just adds dead code that is useless for anybody but the  
original author.


A patch in that state should remain in the private repository of the author.


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

Re: Issue 2165 in lilypond: Patch: Modifies broken hairpin height

[lilypond]

Updates:
Status: Fixed

Comment #8 on issue 2165 by mts...@gmail.com: Patch: Modifies broken  
hairpin height

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

Pushed to staging as 87a8ec69e1ef15aa6e18c11ec7d674ce46e0b5b7.


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

Re: Issue 2149 in lilypond: Patch: Creates non-negative-integer? predicate.

[lilypond]

Updates:
Status: Fixed

Comment #20 on issue 2149 by mts...@gmail.com: Patch: Creates  
non-negative-integer? predicate.

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

Part of the patch pushed to staging as  
6abea44be29f2de2abbc840507c9184132c8024d.
I'm gonna abandon the rest because I have no strong opinion on what the  
name should be and feel that several people have presented good arguments.   
It is a 3ish-line change to the code for whoever wishes to add a new  
predicate.  For now, it will remain ly:vsize?.



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

Re: Issue 2171 in lilypond: Patch: Implements DOM-id property for grobs.

[lilypond]

Updates:
Status: Fixed

Comment #4 on issue 2171 by mts...@gmail.com: Patch: Implements DOM-id  
property for grobs.

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

Pushed to staging as 6abea44be29f2de2abbc840507c9184132c8024d.


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