Uh, oh, please ignore the new stuff.
http://codereview.appspot.com/6459081/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reviewers: Graham Percival,
Message:
I agree with your argumentation. However, I don't have time to fix the
patch. Maybe a good soul from the documentation team can improve this.
Description:
Doc: Improve documentation of \glissando.
Based on work from Tiresia GIUNO .
Please review this at h
LGTM
http://codereview.appspot.com/6542057/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Well done! It's not there yet due to some bugs I believe, but besides
this the code looks OK.
http://codereview.appspot.com/6503091/diff/10001/mf/parmesan-clefs.mf
File mf/parmesan-clefs.mf (right):
http://codereview.appspot.com/6503091/diff/10001/mf/parmesan-clefs.mf#newcode764
mf/parmesan-cl
The glyph shape is OK, thanks. Have you tested the appearance on paper
of all available sizes, using a 300 or 600dpi printer?
http://codereview.appspot.com/6503091/diff/16001/mf/parmesan-clefs.mf
File mf/parmesan-clefs.mf (left):
http://codereview.appspot.com/6503091/diff/16001/mf/parmesan-cle
When you say "paper of all available sizes" I don't understand
why changing the paper size should have any effect.
Could you explain?
Sorry, bad wording. I mean the appearance of all available sizes
printed out on paper.
Is there guidance on the the correct way to calculate
the parameters to
LGTM, except one small issue.
http://codereview.appspot.com/6503091/diff/20001/mf/parmesan-clefs.mf
File mf/parmesan-clefs.mf (right):
http://codereview.appspot.com/6503091/diff/20001/mf/parmesan-clefs.mf#newcode816
mf/parmesan-clefs.mf:816: 2.2 reduced_il#);
The bbox is still too small. I sug
If you do
mf '\mode:=proof; input parmesan20'
gftodvi parmesan20.2602gf
and view the resulting parmesan20.dvi with xdvi, go to your glyph, then
press `10 s' to set the shrink factor to 10. This makes the image small
enough that you can see even the part of the glyph which is below the
lower
LGTM.
http://codereview.appspot.com/6568055/diff/1/mf/feta-scripts.mf
File mf/feta-scripts.mf (right):
http://codereview.appspot.com/6568055/diff/1/mf/feta-scripts.mf#newcode1774
mf/feta-scripts.mf:1774: set_char_box (0, 1.7 staff_space# + epsilon,
I suggest to use a tightest bounding box. At
Please don't use `epsilon' in set_char_box. I think the problem is that
you `sharpen' a coordinate distance by doing `define_pixels (y_off)',
however, only `black distances' (to use the TrueType vocabulary) like
vertical or horizontal stem widths should be handled like that.
In general, I would
LGTM.
http://codereview.appspot.com/6568055/diff/7001/mf/feta-scripts.mf
File mf/feta-scripts.mf (right):
http://codereview.appspot.com/6568055/diff/7001/mf/feta-scripts.mf#newcode1781
mf/feta-scripts.mf:1781: penlabels (1,2,3,4);
z4 is not defined with penpos4, so you should use `labels' inste
LGTM.
http://codereview.appspot.com/6594047/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
http://codereview.appspot.com/6584073/diff/1/python/book_latex.py
File python/book_latex.py (right):
http://codereview.appspot.com/6584073/diff/1/python/book_latex.py#newcode88
python/book_latex.py:88: \\iffalse.*\\fi))''',
On 2012/10/06 02:12:41, Julien Rioux wrote:
.* should be replaced by th
http://codereview.appspot.com/6610058/diff/2001/scripts/convert-ly.py
File scripts/convert-ly.py (right):
http://codereview.appspot.com/6610058/diff/2001/scripts/convert-ly.py#newcode357
scripts/convert-ly.py:357: sys.exit(errors)
Are you going to report the number of errors using the `errors'
v
LGTM now.
http://codereview.appspot.com/6610058/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM, without testing, and without really understanding the change.
However, simplifications and generalizations are always a good thing.
http://codereview.appspot.com/6635050/diff/1/Documentation/de/notation/pitches.itely
File Documentation/de/notation/pitches.itely (right):
http://codereview.
LGTM.
http://codereview.appspot.com/6635050/diff/7002/ly/music-functions-init.ly
File ly/music-functions-init.ly (right):
http://codereview.appspot.com/6635050/diff/7002/ly/music-functions-init.ly#newcode105
ly/music-functions-init.ly:105: (ly:input-warning location (_ "not a
spanner name, `~a'
LGTM.
http://codereview.appspot.com/6742043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
http://codereview.appspot.com/6709073/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM. Any convert rules necessary?
http://codereview.appspot.com/6744070/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
http://codereview.appspot.com/6778055/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM. Nice idea. I'm not sure whether this fits into the large picture
w.r.t. syntax normalization as envisioned by David, but at least for me
it looks reasonable.
http://codereview.appspot.com/6493072/
___
lilypond-devel mailing list
lilypond-devel@
LGTM.
http://codereview.appspot.com/6813079/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Very nice!
http://codereview.appspot.com/6812088/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
http://codereview.appspot.com/6850073/diff/1/scm/define-markup-commands.scm
File scm/define-markup-commands.scm (right):
http://codereview.appspot.com/6850073/diff/1/scm/define-markup-commands.scm#newcode3341
scm/define-markup-commands.scm:3341: breve, longa and maxima are valid
input-strings
Th
LGTM. Do we have a regtest (or rather, an example) which demonstrates
how to use it?
https://codereview.appspot.com/6948058/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
https://codereview.appspot.com/7017044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Everything looks very nice! I just wonder how it comes that those
simplifications haven't been done from the very beginning: Is it
possible that functions like `any' or `every' are new in Scheme?
https://codereview.appspot.com/7020044/
___
lilypond-de
Sorry for being late.
LGTM, with a (not so) minor nit.
https://codereview.appspot.com/6970046/diff/1/LICENSE.OFL
File LICENSE.OFL (right):
https://codereview.appspot.com/6970046/diff/1/LICENSE.OFL#newcode2
LICENSE.OFL:2: Copyright (c) 1996, 1997, ..., 2012, The LilyPond authors
(lilypond.org)
LGTM
https://codereview.appspot.com/7038044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM. Thanks for the quick fix.
https://codereview.appspot.com/7054043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Uh, oh, I failed to use git-cl correctly, so this Rietvield issue is
used for two tracker items... Sorry.
https://codereview.appspot.com/6625078/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-de
LGTM
https://codereview.appspot.com/6970046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
https://codereview.appspot.com/7058068/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
https://codereview.appspot.com/7101045/diff/5001/scm/define-context-properties.scm
File scm/define-context-properties.scm (right):
https://codereview.appspot.com/7101045/diff/5001/scm/define-context-properties.scm#newcode310
scm/define-context-properties.scm:310:
(horizontallyStaggerDifferentVoi
LGTM.
https://codereview.appspot.com/7180043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
https://codereview.appspot.com/7202048/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM, inspite of the compilation error which I can't explain :-)
https://codereview.appspot.com/7312091/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Thanks for the review.
https://codereview.appspot.com/7319049/diff/2001/lily/dot-column.cc
File lily/dot-column.cc (right):
https://codereview.appspot.com/7319049/diff/2001/lily/dot-column.cc#newcode63
lily/dot-column.cc:63: vector allowed_y_positions;
On 2013/02/17 08:20:39, Keith wrote:
It w
... next patch set will follow soon.
https://codereview.appspot.com/7319049/diff/7001/lily/dot-column.cc
File lily/dot-column.cc (right):
https://codereview.appspot.com/7319049/diff/7001/lily/dot-column.cc#newcode206
lily/dot-column.cc:206: p += (int) robust_scm2double
(dp.dot_->get_property ("
We do lose the double-dot on << f'4.. \\ f'2. >>
Yes. As shown in the scanned Beethoven example in #3179, what lilypond
currently does with `chord-dots' off is not correct either...
Well, Gould is showing the usual case, where notes have
Dots.staff-position = 0. You were asking for opinions
LGTM.
https://codereview.appspot.com/7393055/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
https://codereview.appspot.com/7400057/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Very nice, and thanks a lot! From visual inspection only, LGTM.
Just curious: You apparently like the word `junk', however, I find it
not optimal. Can you replace this with `discard' or `cut' within the
command names?
https://codereview.appspot.com/7424049/diff/3002/scm/define-music-types.sc
Much better, thanks!
https://codereview.appspot.com/7424049/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM. Thanks for the good comment :-)
https://codereview.appspot.com/7453046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
From visual inspection, LGTM.
https://codereview.appspot.com/7615043/diff/1/scm/output-lib.scm
File scm/output-lib.scm (right):
https://codereview.appspot.com/7615043/diff/1/scm/output-lib.scm#newcode929
scm/output-lib.scm:929: form. @code{x} is the portion of the width
consumed for a given lin
LGTM
https://codereview.appspot.com/7764046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
https://codereview.appspot.com/7866043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
https://codereview.appspot.com/7583044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM. The combination `\' `\n' `\(' is probably worth a comment in the
contributors' manual.
https://codereview.appspot.com/7742044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM. My only (very minor) concern are overlong lines in the script,
something which I consider hard to read. If possible, stay within the
80 character per line limit.
https://codereview.appspot.com/7578046/
___
lilypond-devel mailing list
lilypond-
https://codereview.appspot.com/7424049/diff/41001/input/regression/repeat-slur.ly
File input/regression/repeat-slur.ly (right):
https://codereview.appspot.com/7424049/diff/41001/input/regression/repeat-slur.ly#newcode10
input/regression/repeat-slur.ly:10: "
This should be rather @code{\\breakSlu
LGTM. I can't help with the problem you are mentioning, but I have the
feeling that the overall code has improved (and probably become simpler
also) w.r.t. previous versions of the patch. Congrats!
https://codereview.appspot.com/7424049/diff/53001/input/regression/repeat-slur.ly
File input/re
LGTM
https://codereview.appspot.com/7836046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
https://codereview.appspot.com/7424049/diff/62001/input/regression/repeat-slur.ly
File input/regression/repeat-slur.ly (right):
https://codereview.appspot.com/7424049/diff/62001/input/regression/repeat-slur.ly#newcode9
input/regression/repeat-slur.ly:9: broken slur at a bar, use
@code{\broken} w
LGTM.
https://codereview.appspot.com/7799048/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
https://codereview.appspot.com/7949044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
https://codereview.appspot.com/8310043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM. Do we have a regtest for this?
https://codereview.appspot.com/8508043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM, with minor nits. Thanks for the patch!
https://codereview.appspot.com/8266047/diff/15001/input/regression/chord-dots.ly
File input/regression/chord-dots.ly (left):
https://codereview.appspot.com/8266047/diff/15001/input/regression/chord-dots.ly#oldcode21
input/regression/chord-dots.ly:21
LGTM, but one patch too much :-)
https://codereview.appspot.com/8266047/diff/19001/ly/titling-init.ly
File ly/titling-init.ly (left):
https://codereview.appspot.com/8266047/diff/19001/ly/titling-init.ly#oldcode144
ly/titling-init.ly:144:
Oops! Changes to this file probably don't belong to this
Why is this patch necessary at all? And what's the value `0.01'?
Please add a comment.
https://codereview.appspot.com/8723043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
https://codereview.appspot.com/8799045/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
https://codereview.appspot.com/8632044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM. Great work!
https://codereview.appspot.com/8189043/diff/45001/Documentation/learning/tweaks.itely
File Documentation/learning/tweaks.itely (right):
https://codereview.appspot.com/8189043/diff/45001/Documentation/learning/tweaks.itely#newcode2288
Documentation/learning/tweaks.itely:2288:
Reviewers: Trevor Daniels,
Message:
OK, will use `protrusion'. `edge-length' is already taken,
unfortunately, for exactly the same thing, namely to control tuplet
brackets. However, this is a pair value, while arpeggio brackets use a
different mechanism (namely the ly:bracket interface) which n
https://codereview.appspot.com/9036044/diff/1/scm/define-context-properties.scm
File scm/define-context-properties.scm (right):
https://codereview.appspot.com/9036044/diff/1/scm/define-context-properties.scm#newcode143
scm/define-context-properties.scm:143: bars (which get bar numbers in
parenth
https://codereview.appspot.com/9073043/diff/1/scm/output-lib.scm
File scm/output-lib.scm (right):
https://codereview.appspot.com/9073043/diff/1/scm/output-lib.scm#newcode861
scm/output-lib.scm:861: (ly:grob-property grob 'outside-staff-padding
0.0))
It would be interesting to know why 1.0 was ad
LGTM
https://codereview.appspot.com/9115043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
https://codereview.appspot.com/8836047/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
https://codereview.appspot.com/8869044/diff/60001/scripts/auxiliar/make-regtest-pngs.sh
File scripts/auxiliar/make-regtest-pngs.sh (left):
https://codereview.appspot.com/8869044/diff/60001/scripts/auxiliar/make-regtest-pngs.sh#oldcode9
scripts/auxiliar/make-regtest-pngs.sh:9: #
Isn't this patch
LGTM.
https://codereview.appspot.com/9073043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM while looking at the code, and I suppose that you are checking all
layout differences :-)
https://codereview.appspot.com/9210044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
https://codereview.appspot.com/9204043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
https://codereview.appspot.com/9705043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
https://codereview.appspot.com/9709043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
https://codereview.appspot.com/9890045/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
MF code LGTM.
http://codereview.appspot.com/5030053/diff/9001/mf/parmesan-noteheads.mf
File mf/parmesan-noteheads.mf (right):
http://codereview.appspot.com/5030053/diff/9001/mf/parmesan-noteheads.mf#newcode497
mf/parmesan-noteheads.mf:497: draw_mensural_longa (m_longa_width,
m_holeheight, true,
LGTM
http://codereview.appspot.com/4951062/diff/24001/mf/feta-kievan.mf
File mf/feta-kievan.mf (right):
http://codereview.appspot.com/4951062/diff/24001/mf/feta-kievan.mf#newcode52
mf/feta-kievan.mf:52: fill z1{dir 8.6} .. z2 .. z3
A minor thing: Please align this vertically (and at similar pla
David, I suggest to apply patches of that kind directly to the
repository without setting up a Rietveld issue.
http://codereview.appspot.com/5437140/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypon
LGTM.
http://codereview.appspot.com/5505090/diff/1/lily/lexer.ll
File lily/lexer.ll (right):
http://codereview.appspot.com/5505090/diff/1/lily/lexer.ll#newcode1009
lily/lexer.ll:1009: case 0xc2:
Wouldn't it be more effective to create an array of 128 bytes (for
0x80-0xFF) which maps `p[i]' to t
LGTM. Will test soon.
http://codereview.appspot.com/5527047/diff/1/lily/lily-guile.cc
File lily/lily-guile.cc (left):
http://codereview.appspot.com/5527047/diff/1/lily/lily-guile.cc#oldcode573
lily/lily-guile.cc:573: int i = scm_to_int (k);
Please apply this cosmetic patch directly to the repo
Thanks, David!
http://codereview.appspot.com/5527058/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
http://codereview.appspot.com/5527058/diff/1/python/convertrules.py
File python/convertrules.py (right):
http://codereview.appspot.com/5527058/diff/1/python/convertrules.py#newcode3362
python/convertrules.py:3362:
From an orthogonal point of view, those variables should be either named
`matchstr
LGTM, but not time to test...
http://codereview.appspot.com/5538049/diff/1/lily/staff-symbol-referencer.cc
File lily/staff-symbol-referencer.cc (right):
http://codereview.appspot.com/5538049/diff/1/lily/staff-symbol-referencer.cc#newcode95
lily/staff-symbol-referencer.cc:95: Real y = (pure
The
Julien,
please apply such obvious (and trivial) fixes directly to lilypond
without creating a Rietveld issue.
http://codereview.appspot.com/5539052/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypon
LGTM.
http://codereview.appspot.com/5695061/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
http://codereview.appspot.com/4273119/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
This kind of patch is something I wouldn't discuss on Rietveld but
rather push immediately...
http://codereview.appspot.com/4724041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
I don't mind if we have another obscure entry in the detail list
currently. If your patches fixes the problem reliably, this would be a
great immediate help.
IMHO, at some point in the hopefully not too distant future, the whole
handling of slurs and ties must be re-examined to make it more
user
LGTM (without testing).
http://codereview.appspot.com/1659041/diff/5001/Documentation/usage/lilypond-book.itely
File Documentation/usage/lilypond-book.itely (right):
http://codereview.appspot.com/1659041/diff/5001/Documentation/usage/lilypond-book.itely#newcode207
Documentation/usage/lilypond-b
http://codereview.appspot.com/4748044/diff/1/mf/feta-noteheads.mf
File mf/feta-noteheads.mf (right):
http://codereview.appspot.com/4748044/diff/1/mf/feta-noteheads.mf#newcode181
mf/feta-noteheads.mf:181: % when there is an interval of fourth.
Wouldn't it be simpler to explicitly specify the line
Aww, i was so proud of this code...
:-)
Frankly, i don't think we will gain anything from defining
a global value. The algorithm i wrote is a bit complicated,
but i thinks is easier to understand than what you suggest
(if i understood your suggestion correctly). It keeps
things in one place
Please use tabs in MF files. Besides that, everythings looks fine.
http://codereview.appspot.com/4808074/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Could you please tell me what this patch is good for? A BOM not at the
beginning of a file is no longer a BOM...
I don't oppose to emitting a warning if U+FEFF is encountered, and we
subsequently ignore it (since its use as zero width no-break space is
deprecated), but only within strings...
Wh
OK.
Please make the warning message more verbose, though.
http://codereview.appspot.com/4908043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
http://codereview.appspot.com/4714043/diff/10001/mf/feta-scripts.mf
File mf/feta-scripts.mf (right):
http://codereview.appspot.com/4714043/diff/10001/mf/feta-scripts.mf#newcode633
mf/feta-scripts.mf:633: height# / 2, height# / 2);
Vertical align mismatch.
http://codereview.appspot.com/47
LGTM.
http://codereview.appspot.com/4921050/diff/2001/python/book_texinfo.py
File python/book_texinfo.py (right):
http://codereview.appspot.com/4921050/diff/2001/python/book_texinfo.py#newcode250
python/book_texinfo.py:250: if (QUOTE in snippet.option_dict):
Why parentheses? Similar lines in t
LGTM. Perhaps you should mention that reducing the line width by 1mm is
a temporary hack.
http://codereview.appspot.com/4940043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
101 - 200 of 722 matches
Mail list logo
