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
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
LGTM.
http://codereview.appspot.com/5695061/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
http://codereview.appspot.com/6351083/diff/1/Documentation/contributor/lsr-work.itexi
File Documentation/contributor/lsr-work.itexi (right):
http://codereview.appspot.com/6351083/diff/1/Documentation/contributor/lsr-work.itexi#newcode209
Documentation/contributor/lsr-work.itexi:209: e.g.
LGTM. Thanks a lot!
http://codereview.appspot.com/6345088/diff/1/Documentation/snippets/simultaneous-headword.ly
File Documentation/snippets/simultaneous-headword.ly (right):
http://codereview.appspot.com/6345088/diff/1/Documentation/snippets/simultaneous-headword.ly#newcode16
I'm currently in Japan, with bad internet access (and additionally, I
can only use the web interface for writing emails, which I heartily
dislike, since SMTP doesn't work here in the hotel for yet unknown
reasons), so it will take some time until I'm able to test this and
communicate with the
http://codereview.appspot.com/6374068/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
This looks great! I don't have time right now to test it, but errors
will be quite easily be caught :-) Thanks for fixing this.
http://codereview.appspot.com/6399046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
Reviewers: ,
Message:
It would be nice if a Russian speaking person could fix the Cyrillic
index entries. However, since we don't have Cyrillic characters in the
index, this is not an urgent issue (and maybe we never need this).
Description:
Add support for Cyrillic in texinfo.
Please review
http://codereview.appspot.com/6459081/diff/1/Documentation/cyrillic.itexi
File Documentation/cyrillic.itexi (right):
http://codereview.appspot.com/6459081/diff/1/Documentation/cyrillic.itexi#newcode14
Documentation/cyrillic.itexi:14: \gdef\cyrfont{%
I fully agree. However, I'm simply mimicking
Notation, section `Kievan contexts', or `snippets/utf-8.ly'.
http://codereview.appspot.com/6459081/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
http://codereview.appspot.com/6459081/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
For example, `Cyrillic letter V' currently maps to the `V', and
`Cyrillic letter G' maps to `G'. [All Cyrillic characters start
with prefix `' so that they get sorted after all Latin letters].
But this is certainly not the correct collation order for Russian!
AFAIK, `Cyrillic letter
LGTM, thanks!
http://codereview.appspot.com/6492045/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
http://codereview.appspot.com/6503091/diff/1/mf/parmesan-clefs.mf
File mf/parmesan-clefs.mf (left):
http://codereview.appspot.com/6503091/diff/1/mf/parmesan-clefs.mf#oldcode885
mf/parmesan-clefs.mf:885:
Your code is not correct. I'm sending comparison images to the
lilypond-devel list.
I'm sorry, but I find this incredibly unhelpful. You've done it
wrong
is insulting to someone who's spent about 40 hours trying to get it
right.
The original code was wrong, with any number of incorrect assumtions.
If you could point me to what is incorrect, I'll try to fix it. I see
There isn't any indentation standard for mf files, is there?
It's implicitly given by the formatting of all MF files. I know that
this is far from ideal, but unless someone is stepping forward to write
a specification for GNU indent or something similar so that the
indentation can be enforced
I was aware of a slight difference, although actually I'm
not certain it's that important - these are machine drawn
glyphs intending to replicate hand-drawn clefs from the
15th century. How important is 0.1 staff space?
This is not the point. Your are changing the shape without documenting
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 tires...@googlemail.com.
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
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):
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
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
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'
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
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'
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):
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,
http://codereview.appspot.com/193077/diff/1001/12
File lily/general-scheme.cc (right):
http://codereview.appspot.com/193077/diff/1001/12#newcode230
lily/general-scheme.cc:230: return ((c = 0x2D c = 0x2F) // hyphen,
full-stop, and forward-slash
Wouldn't it be faster to use an array of `0' and
http://codereview.appspot.com/1817045/diff/1/4
File scm/define-grob-properties.scm (right):
http://codereview.appspot.com/1817045/diff/1/4#newcode1059
scm/define-grob-properties.scm:1059:
Since the properties in this file are sorted alphabetically, this is the
wrong place...
LGTM too.
http://codereview.appspot.com/2275042/diff/18001/lily/stencil-scheme.cc
File lily/stencil-scheme.cc (right):
http://codereview.appspot.com/2275042/diff/18001/lily/stencil-scheme.cc#newcode398
lily/stencil-scheme.cc:398: {
Don't say @co...@var{...}} but @var{...}.
http://codereview.appspot.com/2754041/diff/1/lily/general-scheme.cc
File lily/general-scheme.cc (right):
http://codereview.appspot.com/2754041/diff/1/lily/general-scheme.cc#newcode84
lily/general-scheme.cc:84: If @var{size} is @code{SCM_UNDEFINED}, the
entire file is read.
To be in sync with
http://codereview.appspot.com/2726043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Oops, somehow I've just created an empty comment.
http://codereview.appspot.com/2726043/diff/1/ly/music-functions-init.ly
File ly/music-functions-init.ly (right):
http://codereview.appspot.com/2726043/diff/1/ly/music-functions-init.ly#newcode238
ly/music-functions-init.ly:238: cleffedCueDuring
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
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
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
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...
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.
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
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
http://codereview.appspot.com/4951062/diff/1/mf/feta-kievan.mf
File mf/feta-kievan.mf (right):
http://codereview.appspot.com/4951062/diff/1/mf/feta-kievan.mf#newcode78
mf/feta-kievan.mf:78: fill z1{dir -6.9} .. z2 .. z3 z3 .. z4 .. z5
z5 -- z6 z6 .. z7 .. z8 z8{left} .. z9 z9 .. z10 ...
Simply have a look how other note heads are implemented, and watch how
the shape changes for different design sizes.
http://codereview.appspot.com/4951062/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://codereview.appspot.com/4951062/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
OK. What is noteheight# equal to and how is that determined?
A quick grep on the MF files shows that noteheight# is defined in
feta-params.mf.
http://codereview.appspot.com/4951062/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
LGTM
Werner
http://codereview.appspot.com/4639065/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
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
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
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
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
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
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
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/
___
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
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:
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: vectorInterval allowed_y_positions;
On 2013/02/17 08:20:39, Keith
... 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
on
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?
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
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
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
1 - 100 of 713 matches
Mail list logo
