https://codereview.appspot.com/108700043/diff/80001/scm/font.scm
File scm/font.scm (right):
https://codereview.appspot.com/108700043/diff/80001/scm/font.scm#newcode241
scm/font.scm:241: Construct a font tree consisting of the default Feta
music font and
I think an explanation and clear example
Reviewers: ,
Message:
Hi, in this patchset on Rietveld, instead of displaying the diff, two of
the modified files just say
error: old chunk mismatch
They are
Documentation/contributor.texi
Documentation/web.texi
I rebased and reuploaded, but still got the same error. How do I
correct
Reviewers: ,
Message:
Here are some improvements to magnifyMusic and magnifyStaff. Nothing
major, but please have a look. Also, I'm still hoping to get a little
more discussion on my earlier -devel thread:
http://lists.gnu.org/archive/html/lilypond-devel/2014-07/msg00260.html
Thanks,
Mark
On 2014/07/29 05:35:40, Keith wrote:
https://codereview.appspot.com/114160044/diff/1/scm/define-grob-properties.scm#newcode902
scm/define-grob-properties.scm:902: @code{right-edge}; otherwise it is
fixed.
Looking at the code, 'right-edge' would seem to be among the
otherwise it is
fixed
Reviewers: ,
Message:
Since no one reviewed this patch, I'm setting its status back to review.
I'll push it next countdown if I all remains quiet.
Thanks,
Mark
Description:
Things take so long to understand when they're not documented!
Issue 4024 on the tracker:
https://codereview.appspot.com/114840043/diff/80001/Documentation/notation/notation-appendices.itely
File Documentation/notation/notation-appendices.itely (right):
https://codereview.appspot.com/114840043/diff/80001/Documentation/notation/notation-appendices.itely#newcode1513
https://codereview.appspot.com/108700043/diff/80001/input/regression/font-expert-selection.ly
File input/regression/font-expert-selection.ly (right):
https://codereview.appspot.com/108700043/diff/80001/input/regression/font-expert-selection.ly#newcode33
https://codereview.appspot.com/116990043/diff/1/Documentation/notation/pitches.itely
File Documentation/notation/pitches.itely (right):
https://codereview.appspot.com/116990043/diff/1/Documentation/notation/pitches.itely#newcode2446
Documentation/notation/pitches.itely:2446: suppressed for
https://codereview.appspot.com/112280043/diff/40001/Documentation/contributor/administration.itexi
File Documentation/contributor/administration.itexi (right):
https://codereview.appspot.com/112280043/diff/40001/Documentation/contributor/administration.itexi#newcode354
https://codereview.appspot.com/115770043/diff/1/lily/page-layout-problem.cc
File lily/page-layout-problem.cc (left):
https://codereview.appspot.com/115770043/diff/1/lily/page-layout-problem.cc#oldcode38
lily/page-layout-problem.cc:38: Returns the number of footntoes
associated with a given
On 2014/07/20 23:48:12, david.nalesnik wrote:
https://codereview.appspot.com/117830043/diff/80001/ly/music-functions-init.ly#newcode721
ly/music-functions-init.ly:721: (BarLine kern)
Shouldn't this now be segno-kern?
Done.
Regarding the naming, looks like it's a tie between `resize' and
On 2014/07/17 12:44:20, david.nalesnik wrote:
https://codereview.appspot.com/117830043/diff/60001/input/regression/magnifyStaff-bar-lines.ly#newcode30
input/regression/magnifyStaff-bar-lines.ly:30:
Are so many examples necessary?
No. I've reduced from 5 examples to 3.
Reviewers: ,
Message:
Here's a new music function called \magnifyStaff (along the lines of
\magnifyMusic) that scales staff sizes, staff lines, bar lines,
beamlets, and horizontal spacing at the Staff context level. Staff
lines are prevented from being scaled smaller than the default (and
Reviewers: dak,
Message:
On 2014/07/09 07:02:48, dak wrote:
https://codereview.appspot.com/110960043/diff/1/scm/define-grob-properties.scm
File scm/define-grob-properties.scm (right):
https://codereview.appspot.com/110960043/diff/1/scm/define-grob-properties.scm#newcode243
On 2014/07/09 00:16:50, Mark Polesky wrote:
Good idea, Harm. I started a new issue to take care of that:
http://code.google.com/p/lilypond/issues/detail?id=3999
http://codereview.appspot.com/101690043/
Oops, wrong links.
Tracker: http://code.google.com/p/lilypond/issues/detail?id=3999
Reviewers: dak,
Message:
On 2014/07/09 23:46:36, dak wrote:
https://codereview.appspot.com/112040043/diff/1/Documentation/contributor/doc-work.itexi#newcode950
Documentation/contributor/doc-work.itexi:950:
@samp{The@tie{}@@code@{@bs{}foo@}@tie{}command}). However, if a
Why write @bs{} instead
On 2014/07/09 23:55:49, Mark Polesky wrote:
On 2014/07/09 23:46:36, dak wrote:
https://codereview.appspot.com/112040043/diff/1/Documentation/contributor/doc-work.itexi#newcode955
Documentation/contributor/doc-work.itexi:955: The
@@code@{@bs{}@bs{}foo@}
command...
That's awfully
On 2014/07/09 07:13:04, Mark Polesky wrote:
...But TabStaff is not a regular staff, since its staff-lines are
further apart (i.e. the default TabStaff.Symbol.staff-space = 1.5).
Pardon the typo; I meant TabStaff.StaffSymbol.staff-space of course.
https://codereview.appspot.com/110960043/
marc wrote:
OK, but 'thin-kern does not seem to be an
appropriate name for this property anymore IMHO.
How about 'segno-kern? (patch updated accordingly)
https://codereview.appspot.com/105560044/
___
lilypond-devel mailing list
Reviewers: ,
Message:
continued from http://codereview.appspot.com/103890046/#msg11
On 2014/07/07 18:22:09, dak wrote:
https://codereview.appspot.com/103890046/diff/250001/ly/music-functions-init.ly#newcode718
ly/music-functions-init.ly:718: \context Voice {
This would create a new Staff when
Reviewers: ,
Message:
Hi, I'm proposing to get rid of the BarLine.thin-kern property with this
patch, so if you're opposed, let me know.
You can see my comments/rationale here:
http://code.google.com/p/lilypond/issues/detail?id=3995
Thanks,
Mark
Description:
This removes the thin-kern
On 2014/07/06 11:52:56, thomasmorley651 wrote:
I disagree!
'kern and 'thin-kern _are_ used differently.
Look at the output from:
Harm,
what am I missing? To my eye (compiling this with the latest snapshot),
your example shows that thin-kern does nothing.
- Mark
On 2014/07/06 11:52:56, thomasmorley651 wrote:
I disagree!
'kern and 'thin-kern _are_ used differently.
Okay, so then it's just a question of clarifying the misleading
docstrings. How about this?
kern
The space between individual elements in any compound bar line.
thin-kern
The space
On 2014/07/06 14:04:07, dak wrote:
ly/music-functions-init.ly:645: Stem.thickness
This is madness. Stem.thickness and its ilk don't make sense as
symbols at all
Okay
ly/music-functions-init.ly:679: Slur.details.region-size
I doubt you even have a chance of making this work. Overriding and
On 2014/07/05 05:28:36, J_lowe wrote:
Okay, but \clef tab needs \new TabStaff as well
Well I've never used Tab notation before and lilypond will let you
compile
\clef tab c1
It will let you compile, but the visual output is still wrong.
So if you *always* use a \new TabStaff for \clef
Reviewers: J_lowe, pwm,
Message:
On 2014/07/05 14:17:23, pwm wrote:
Happened to see another little simplification.
...
Can be simplified: (lambda (x) x) is the same as x
Not in this case; guile would complain about unbound variable x. I
could have used the guile function `identity', but I
https://codereview.appspot.com/108130043/diff/90001/Documentation/changes.tely
File Documentation/changes.tely (right):
https://codereview.appspot.com/108130043/diff/90001/Documentation/changes.tely#newcode68
Documentation/changes.tely:68: Add support for @code{\once}@code{\unset}
https://codereview.appspot.com/106160043/diff/20001/ROADMAP
File ROADMAP (right):
https://codereview.appspot.com/106160043/diff/20001/ROADMAP#newcode21
ROADMAP:21: | | Note: Snippets and Internals Reference are
auto-generated
| | Note: Snippets and Internals Reference are
| |
https://codereview.appspot.com/104520043/diff/1/Documentation/notation/notation-appendices.itely
File Documentation/notation/notation-appendices.itely (right):
https://codereview.appspot.com/104520043/diff/1/Documentation/notation/notation-appendices.itely#newcode1489
https://codereview.appspot.com/106320046/diff/1/Documentation/snippets/new/printing-bar-numbers-with-changing-regular-intervals.ly
File
Documentation/snippets/new/printing-bar-numbers-with-changing-regular-intervals.ly
(right):
Reviewers: janek, Keith, dak,
Message:
I've rewritten the \applyContext description, and this new patch is
about 40% shorter than the previous one. Please review.
Thanks,
Mark
Description:
The documentation on \applyContext is pretty slim. I'm just mentioning
some new tricks I recently
On 2014/07/04 10:29:15, J_lowe wrote:
The problem is (else I would have done what you suggested) is that one
cannot
just use
\clef moderntab { c1 } and it will print like \clef tab { c1 }, so I
was trying
to show that to get that specific clef you must (so it seems) use the
\new
On 2014/07/04 20:47:24, janek wrote:
Hi Mark,
do you have any objections against putting this patch on countdown?
No objections, but I'll leave it to someone else to give the green light
since I'm not qualified to evaluate the C++ code.
As i wrote, this is a transitional phase: the patch
Janek Warchoł wrote:
While I think that it's better to always align lyrics to
the main notehead, I knew that some people would prefer
to do this otherwise, so the patch allows to choose how to
align LyricTexts (and DynamicTexts)
Okay, this is less problematic than I thought it was, and
I'm
This patch is problematic for me.
Firstly, when a lyric syllable extends to the next note (as with a slur
or tie), it is my understanding that the lyric text should be
left-aligned with the left-most note of the chord. See Issue 3521:
http://code.google.com/p/lilypond/issues/detail?id=3521
This new patch went through a countdown cycle without any
reviews. I'm putting it through another cycle in case
anyone would like to make comments before I push it.
Thanks.
- Mark
https://codereview.appspot.com/103890046/
___
lilypond-devel mailing
Apart from my overly fussy nitpicks, LGTM.
https://codereview.appspot.com/106160043/diff/1/ROADMAP
File ROADMAP (right):
https://codereview.appspot.com/106160043/diff/1/ROADMAP#newcode21
ROADMAP:21: | | Note: The Snippets and Internals manual are
auto-generated
I might say:
Note:
On 2014/06/15 05:25:27, dak wrote:
It would have helped if I had written the correct command to use. It
is, of course, \applyContext.
The documentation does not help much, but one illustrative
read/modify/write use is in scm/music-functions.scm in
add-grace-property and
Now that this patch is in the git repo, I decided to import the LSR to
Git, following the instructions in CG 7.4:
http://lilypond.org/doc/v2.19/Documentation/contributor/lsr-to-git
However, on the last step (manually checking for unsafe files), it
became abundantly clear that I am *not* the
On 2014/06/14 10:03:46, mail_philholmes.net wrote:
I would suggest correcting the links in the Documentation, but not the
snippets themselves. The links in the snippets are not really visible
(commented out) and, as James says, are over-written with an LSR
import.
Fair enough. I
On 2014/06/14 06:58:52, dak wrote:
On 2014/06/06 09:29:03, Mark Polesky wrote:
... Ideally, if the user has already
modified some of those values, I'd like to base the new scaled values
on
the user's choices, and not base them on the LilyPond default values.
If that's possible at all, I don't
On 2014/06/06 09:29:03, Mark Polesky wrote:
Please review this new patch. I'm not entirely sure this
is the right approach, so I may need some advice here.
This patch has gone through the review/countdown process without a
single comment or review, but I'm not comfortable pushing it without
Reviewers: ,
Message:
I'm seeing some confusion on -user due to the broken LSR links. Here's
an (unavoidably large) patch to fix the links.
- Mark
Description:
Issue 3951: Fix broken LSR links in docs.
Not sure why, but the URL for the LSR seems to have changed from:
lsr.dsi.unimi.it
to
Reviewers: ,
Message:
Please review this new patch. I'm not entirely sure this is the right
approach, so I may need some advice here.
Thank you!
- Mark
Description:
This is a (possibly misguided) attempt to get slurs and ties to scale
properly when using \magnifyMusic. For the most part,
On 2014/05/26 01:27:49, Mark Polesky wrote:
Hi all,
James has reported that this patch has somehow triggered an error in
the
mozart-hrn-3.ly regtest, which makes no sense to me:
https://code.google.com/p/lilypond/issues/detail?id=3926#c3
To anyone jumping in here, the error has been
Reviewers: dak,
Message:
On 2014/06/01 15:10:59, dak wrote:
scm/lily.scm:728: (,ly:undead? . undead object)
Probably more like an undead container as the undead thing (to
survive between
sessions) is placed inside.
Won't be helpful information to somebody reading the manual which is
the
On 2014/05/31 07:13:17, dak wrote:
https://codereview.appspot.com/95710044/diff/150001/scm/lily-library.scm
File scm/lily-library.scm (right):
https://codereview.appspot.com/95710044/diff/150001/scm/lily-library.scm#newcode948
scm/lily-library.scm:948: (define (ly-type? x)
Is this
Reviewers: ,
Message:
Here's a new patch to tidy up the IR a little bit. Please review.
- Mark
Description:
This patch uses (pretty-print) instead of (display) to show some IR
properties, such as alists and vectors, that are really hard to read as
it stands.
It increases the internals.pdf
https://codereview.appspot.com/95710044/diff/20001/scm/documentation-lib.scm
File scm/documentation-lib.scm (right):
https://codereview.appspot.com/95710044/diff/20001/scm/documentation-lib.scm#newcode112
scm/documentation-lib.scm:112: (or (vector? val) ; vector is an ly-type
On 2014/05/30
On 2014/05/30 09:11:57, Mark Polesky wrote:
https://codereview.appspot.com/95710044/diff/20001/scm/documentation-lib.scm#newcode144
scm/documentation-lib.scm:144: (string-regexp-substitute \n \n
str)))
On 2014/05/30 08:38:23, dak wrote:
pretty-print has a key #:per-line-prefix. Would
On 2014/05/30 10:45:36, dak wrote:
; (ly-type? vector) = #t
That's rubbish. None of the given types in ly-type? should trigger
for a
vector. And indeed it would appear that the definition of
ly:music-list? is
broken and returns #t for anything that is not a list.
Your new commit
Reviewers: dak,
https://codereview.appspot.com/102760044/diff/1/scm/document-backend.scm
File scm/document-backend.scm (right):
https://codereview.appspot.com/102760044/diff/1/scm/document-backend.scm#newcode22
scm/document-backend.scm:22: (apply eq? #t (map pair? x
On 2014/05/28 00:00:58,
David's logic has convinced me to retract the alist-sorting of the
previous patch. What remains is just a minor cleanup of the sorting
code, which is hopefully now easier to understand.
Please review the new patch.
Thanks.
- Mark
https://codereview.appspot.com/102760044/
On 2014/05/28 21:46:55, dak wrote:
Doing an assoc-set! here is inefficient inside of the loop. Instead
of
(for-each
(lambda (grob-description)
...
(set! all-grob-descriptions (assoc-set! ...
one should use
(set! all-grob-descriptions
(map!
(lambda
Hi all,
James has reported that this patch has somehow triggered an error in the
mozart-hrn-3.ly regtest, which makes no sense to me:
https://code.google.com/p/lilypond/issues/detail?id=3926#c3
If this in fact the case, can someone help identify the error, and how I
can fix it? Because I have
https://codereview.appspot.com/13300048/diff/9001/Documentation/changes.tely
File Documentation/changes.tely (right):
https://codereview.appspot.com/13300048/diff/9001/Documentation/changes.tely#newcode86
Documentation/changes.tely:86: of the clef and key signature by default.
As in previous
https://codereview.appspot.com/7005056/diff/35015/Documentation/learning/tweaks.itely
File Documentation/learning/tweaks.itely (right):
https://codereview.appspot.com/7005056/diff/35015/Documentation/learning/tweaks.itely#newcode2987
Documentation/learning/tweaks.itely:2987: \override
https://codereview.appspot.com/13290047/diff/5001/stepmake/stepmake/generic-targets.make
File stepmake/stepmake/generic-targets.make (right):
https://codereview.appspot.com/13290047/diff/5001/stepmake/stepmake/generic-targets.make#newcode56
stepmake/stepmake/generic-targets.make:56: @echo
Here's a revised doc patch that I started last month.
Feel free to review.
Thanks.
- Mark
https://codereview.appspot.com/10759043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Here's a patch that adds a new context, NullVoice, to
provide users with an easier way to have shared lyrics among
polyphonic voices, which also allows using lyrics with
\partcombine. This is a complete rewrite of a similar patch
from a month ago.
Please review.
Thanks!
- Mark
David Kastrup wrote:
I vote to go ahead with adding \displayMarkup.
Huh? Can you name a _single_ advantage that is gained
by having \displayMarkup (which is only different from
\displayScheme by refusing to accept a number of
arguments) instead of \displayScheme?
Of course not. I meant
Reviewers: Trevor Daniels,
Message:
On 2013/08/14 21:35:16, Trevor Daniels wrote:
Should this not be @ref{...}?
No. @rinternals{...}. See
http://lilypond.org/doc/v2.17/Documentation/contributor/syntax-survey#cross-references
- Mark
Description:
Remove 'thickness from LedgerLineSpanner
On 2013/08/15 07:24:48, dak wrote:
That documentation states as first entry:
@ref{…} — link within current manual.
Well, shoot. That's why we have a countdown. Sorry for the
mistake. Just, um, asserting my humanity, I guess...
Anyway, I made the change.
- Mark
David Kastrup wrote:
Any chance to join them completely?
Not yet. It's a long-term goal. And of course, there are a
few things that are not easily reconciled: compare
\void\displayScheme -5
with
\void\displayMusic -5
Well, I played around with this, and David's example is
pretty
Reviewers: ,
Message:
Hi all, here's a new patch.
- Mark
Description:
Issue 3491: http://code.google.com/p/lilypond/issues/detail?id=3491
Please review this at https://codereview.appspot.com/12732043/
Affected files:
M Documentation/extending/programming-interface.itely
M
On 2013/07/18 20:47:05, dak wrote:
Folks, this is the reference manual, not obscure hacks
for adventureous geeks. If we anticipate that a task is
common enough to warrant an entry in the reference manual,
it warrants a user interface.
Fair enough.
We might or might not want to cobble this
On 2013/07/19 08:27:20, dak wrote:
Ok. Is the _output_ from the following what you'd consider
appropriate?
sopranoNotes = { c''2 d''4 e'' }
altoNotes = { \repeat unfold 8 { a'16 g'16 } }
words = \lyricmode { Oh my head }
\new Staff \with { printPartCombineTexts = ##f \accepts Devnull
On 2013/07/19 10:48:43, dak wrote:
To be clear, there are two separate effects I'd like to
achieve with this one interface:
1) aligning lyrics to one of the two partcombined voices
2) aligning lyrics to a third (hidden) voice, without
altering spacing
It's more like
3) aligning
David,
I've been playing around with your Devnull workaround, and
it's great! An independent aligner voice works as long as
there are NoteColumns in the printed voices that it can line
up with, though this is still really useful. (I'm willing
to put aside the averaging NoteColumn X-positions
Reviewers: ,
Message:
Hi folks,
here's a patch that adds a new snippet to NR Automatic part combining:
my workaround to get \partcombine to work with lyrics. Is the texidoc
too long? Should I leave out how it works?
http://code.google.com/p/lilypond/issues/detail?id=3457
Thanks
- Mark
Reviewers: ,
Message:
Graham,
this is for you. Here's a patch for the GUB repo.
https://codereview.appspot.com/10822043/
Just cleaning up some old cobwebs in the tracker.
Can you push it to GUB master and marked issue 1337 as fixed?
http://code.google.com/p/lilypond/issues/detail?id=1337
On 2013/07/01 07:27:41, J_lowe wrote:
And this is why.
There has been no label change on this to know that it needs to be
tested
before it is then reviewed,
Fortunately you at least put the tracker number in the summary.
So I will go and change that for you so it gets tested.
Ah. I
Also, I don't have time to compile right now, but I don't suppose it
also prints a version stamp in the older docs, like 2.12 and 2.14?
Otherwise it doesn't really satisfy the original request on the tracker
- http://code.google.com/p/lilypond/issues/detail?id=3367 . Personally,
I think the real
https://codereview.appspot.com/10782045/diff/1/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):
https://codereview.appspot.com/10782045/diff/1/Documentation/notation/input.itely#newcode921
Documentation/notation/input.itely:921: opus = \markup { \italic Op.
13
Reviewers: ,
Message:
I don't know if this qualifies for a Fixed label on Issue 519, but let
me know what you think.
http://code.google.com/p/lilypond/issues/detail?id=519
Thanks.
- Mark
Description:
Issue 519: Warn about cross-platform font inconsistencies.
Please review this at
https://codereview.appspot.com/10506043/diff/1/python/auxiliar/postprocess_html.py
File python/auxiliar/postprocess_html.py (right):
https://codereview.appspot.com/10506043/diff/1/python/auxiliar/postprocess_html.py#newcode60
python/auxiliar/postprocess_html.py:60: sidebar_version = _doc ('
Reviewers: ,
Message:
Hey all,
just randomly fixing an old issue.
https://codereview.appspot.com/10700044
- Mark
Description:
Issue 1168: website graphical design
On the website home page:
Center the `squiggle' graphic.
Add vertical space between news posts.
Please review this at
On 2011/12/17 14:20:44, Graham Percival wrote:
Try this:
git grep share/lilypond
apparently it's in the Learning manual, which is bad because it
should be covered in Usage. or rather: it's ok to have it
discussed in Learning, but only as long as the reference
material is in Usage.
Reviewers: ,
Message:
Issue 3190 lists 2 separate problems, w3c compliance and lynx
compatibility:
http://code.google.com/p/lilypond/issues/detail?id=3190
I've fixed the w3c compliance problem, though I haven't checked the lynx
problem. If the lynx thing is still problematic, someone should
Hey guys,
I don't want to be presumptuous here, but is there any
chance I can be credited for the original idea? Or is
that not typically done in the snippets directory?
http://lists.gnu.org/archive/html/lilypond-devel/2009-07/msg00590.html
Figuring that out was a proud moment for me!
Hope
Thanks again to everyone here for helping to finish what I
started. I'll leave the style/content issues to the rest of
you; the comments below are just nitpicks.
- Mark
http://codereview.appspot.com/4124056/diff/18001/Documentation/notation/input.itely
File Documentation/notation/input.itely
Reviewers: ,
Message:
Hey guys.
Here's a complete rewrite of
NR 3.2 Titles and headers.
Please comment. You can disregard the first couple
of patch sets, and go straight to the First Draft
one.
Thanks.
- Mark
Description:
Rewrite NR 3.2 Titles and headers.
Please review this at
I ran `make check' and this patch doesn't break anything,
so I'll just push it.
- Mark
http://codereview.appspot.com/3465041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Pushed and closed. Thanks guys.
- Mark
http://codereview.appspot.com/3406041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reviewers: ,
Message:
Here's a patch following the discussion here:
http://lists.gnu.org/archive/html/lilypond-devel/2010-12/msg00034.html
- Mark
Description:
Clean up declarations-init.ly, paper-defaults-init.ly.
Please review this at http://codereview.appspot.com/3465041/
Affected files:
Hey guys, I made some requested changes.
How does this look?
- Mark
http://codereview.appspot.com/3406041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reviewers: ,
Message:
Here's a patch to clean up the NR spacing chapter a little
more. Does everything look okay?
Thanks.
- Mark
Description:
Doc: NR 4: Minor edits.
Please review this at http://codereview.appspot.com/3406041/
Affected files:
M Documentation/notation/spacing.itely
On 2010/11/20 08:44:51, Trevor Daniels wrote:
LGTM
Patch pushed and issue closed.
http://codereview.appspot.com/3199041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2010/11/21 08:55:01, Trevor Daniels wrote:
Looks good to go to me
Trevor
Patch pushed and issue closed. Thanks to everyone who helped out.
This is a big change and I'm glad to see it finished!
- Mark
http://codereview.appspot.com/2758042/
On 2010/11/20 01:23:07, Keith wrote:
Misplaced underscore tag for translation?
Oops. Fixed, thanks.
On 2010/11/20 00:12:19, Graham Percival wrote:
I would rather wait another 23.5 hours, to give people in
all timezones (regardless of geographic location; I'm
living in Pacific Standard Time
Patch set 7. We're down to nitpicks here...
I can't really think of a good way to break this up, except
into 2 commits, the 2nd being far larger than the first.
1) Organize paper-defaults-init.ly.
2) Doc: NR 4.1, 4.2: Reorganize, clarify details.
Okay, this small patch is finished. Graham, would you like
me to wait to push this for any reason?
- Mark
http://codereview.appspot.com/3199041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
Reviewers: ,
Message:
If I understand correctly, head-separation and
foot-separation are gone. This patch just removes the
vestiges from scm/ and ly/, but I suppose we should provide
a convert-ly rule?
So, in an earlier patch by Alexander...
Hi guys,
Patch set 5 finally makes the changes that Carl requested
from the beginning: it's better to refer to a file where
default values are defined, than to list them in the
property descriptions. I've now done this, and I think this
thing is ready to commit.
However, I'd like to point out
On 2010/11/18 17:51:55, Graham Percival wrote:
I'm getting a bit confused with all the renamings,
reorganizations, etc., and I can't be the only one. Could
we slow things down slightly? I'd like to see only one
spacing patch on the table at once, and leaving 24 hours
after the final draft of
Patch set 4 uploaded.
- Mark
http://codereview.appspot.com/2758042/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Guys, I totally reorganized things yet again, and added a
lot of useful info. I am aware that many of your previous
comments have not been addressed yet (I'm not ignoring
them). But I'd like to know what you guys think of the new
text and organization. This is still a work in progress
Thanks, Trevor. Okay to push this now?
- Mark
http://codereview.appspot.com/3089042/diff/1/Documentation/notation/spacing.itely
File Documentation/notation/spacing.itely (right):
http://codereview.appspot.com/3089042/diff/1/Documentation/notation/spacing.itely#newcode1672
Reviewers: ,
Message:
Just some clean-ups to NR 4.4.1 Flexible vertical spacing
within systems.
Any objections? Okay to push?
- Mark
Description:
Doc: NR 4.4.1: Clean up property descriptions.
Please review this at http://codereview.appspot.com/3089042/
Affected files:
M
On 2010/11/13 17:33:47, Graham Percival wrote:
This patch cannot be applied to current master.
Please withdraw the patch, or rewrite it to match the
post-renaming spacing docs. If you opt to rewrite it,
then Mark Polesky can help you.
Graham,
I don't want to be a spoilsport, but I have a
1 - 100 of 138 matches
Mail list logo
