Reviewers: joeneeman,
Message:
Thanks for your review, Joe.
On 2009/07/07 18:32:44, joeneeman wrote:
http://codereview.appspot.com/91075/diff/1/3
File scm/output-svg.scm (right):
http://codereview.appspot.com/91075/diff/1/3#newcode140
Line 140: (match:substring match 1)))
Why not just (set-a
On 2009/07/07 21:10:54, Patrick McCarty wrote:
> http://codereview.appspot.com/91075/diff/1/3#newcode155
> Line 155: (set! alist (reverse alist))
> You can use reverse! here
Oddly, this did not work. I tried
(reverse! alist)
(apply entity 'text expr alist)))
Never mind. Patch Set
http://codereview.appspot.com/74056/diff/1/2
File scm/translation-functions.scm (right):
http://codereview.appspot.com/74056/diff/1/2#newcode109
Line 109: #:general-align Y DOWN
The accidentals look nicer now, but this breaks the alignment for the
figured bass continuation lines and numbers. Se
http://codereview.appspot.com/8874/diff/2201/3202
File scm/define-markup-commands.scm (right):
http://codereview.appspot.com/8874/diff/2201/3202#newcode2625
Line 2625: (find-brace (binary-search 0 575 get-y-from-brace
scaled-size))
Would Open_type_font::count () return the value 575 you need her
Reviewers: joeneeman,
http://codereview.appspot.com/96083/diff/1/8
File lily/pango-font.cc (right):
http://codereview.appspot.com/96083/diff/1/8#newcode351
Line 351: // options.
On 2009/07/21 18:43:10, joeneeman wrote:
Could you please have a look at this? (after applying this patch, if
you
I don't really understand the code from this patchset, but I just have
one quick comment.
Thanks,
Patrick
http://codereview.appspot.com/97119/diff/1/22
File lily/staff-grouper-engraver.cc (right):
http://codereview.appspot.com/97119/diff/1/22#newcode21
Line 21: {
Are engravers allowed to inher
On 2009/08/17 21:40:16, Neil Puttock wrote:
On 2009/08/17 02:57:15, hanwenn wrote:
> http://codereview.appspot.com/107046/diff/1/3
> File lily/staff-symbol-referencer-scheme.cc (right):
>
> http://codereview.appspot.com/107046/diff/1/3#newcode45
> Line 45: " with @var{grob}.")
> fix indents
On 2008/10/09 21:25:50, Neil Puttock wrote:
On 2008/10/08 03:37:15, hanwenn wrote:
> LGTM, but I don't understand what this has to do with the error
messages you
> mention.
Apologies, it is a bit vague.
Using -ddelete-intermediate-files with -dbackend=eps generates an
error:
In proce
http://codereview.appspot.com/109070/diff/1/2
File lily/general-scheme.cc (right):
http://codereview.appspot.com/109070/diff/1/2#newcode432
Line 432: else if (scm_is_string (arg)) {
Can you also fix the indentation (move open brace to next line) and
below likewise?
http://codereview.appspot.com
http://codereview.appspot.com/143055
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
http://codereview.appspot.com/143055/diff/19/1020
File scm/lily-library.scm (right):
http://codereview.appspot.com/143055/diff/19/1020#newcode99
Line 99: (for-each (lambda (symbol)
I would recommend indenting like so:
(for-each
(lambda (symbol)
(let ((..
http://codereview.appspot.c
http://codereview.appspot.com/143055/diff/19/1020
File scm/lily-library.scm (right):
http://codereview.appspot.com/143055/diff/19/1020#newcode99
Line 99: (for-each (lambda (symbol)
I would recommend indenting like so:
(for-each
(lambda (symbol)
(let ((..
http://codereview.appspot.c
http://codereview.appspot.com/143055
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reviewers: Neil Puttock,
Message:
On 2009/11/12 20:38:57, Neil Puttock wrote:
Hi Patrick,
This looks fine to me.
Thanks, Neil. I pushed the patches.
-Patrick
Description:
Source_file: remove mbrtowc() in favor of utf8_char_len()
- Move the routine to determine length of UTF-8 characters
Reviewers: joeneeman,
Message:
On 2010/01/10 05:03:30, joeneeman wrote:
http://codereview.appspot.com/186054/diff/1/2
File lily/pango-font.cc (right):
http://codereview.appspot.com/186054/diff/1/2#newcode384
lily/pango-font.cc:384: bool to_paths = get_program_option
("music-strings-to-paths")
Reviewers: lemzwerg, dak,
Message:
On 2010/01/25 09:28:36, dak wrote:
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,
f
http://codereview.appspot.com/203054/diff/1/2
File lily/system.cc (right):
http://codereview.appspot.com/203054/diff/1/2#newcode310
lily/system.cc:310: {
Hi Neil,
I'm not really sure about the order of operations here, but I noticed
something else:
Removing the 'after-line-breaking callback fr
Han-Wen,
I'm can't see this patch in its entirety, because I think some of the
files failed to upload to Rietveld.
Can you try reuploading your patch, even to a new issue if necessary?
Thanks,
Patrick
http://codereview.appspot.com/248041/show
___
l
LGTM.
Since this commit removes the need for the feta-alphabet Type-1 fonts,
we no longer need to distribute them, but that's something that can be
done at a later time.
Thanks,
Patrick
On 2010/03/05 15:13:25, hanwenn wrote:
Hey - can you look again,
in addition to failing the upload I als
I just realized that this breaks the SVG backend, but I have a patch for
that, so you don't need to worry about it.
Thanks,
Patrick
On 2010/03/06 21:25:28, Patrick McCarty wrote:
LGTM.
Since this commit removes the need for the feta-alphabet Type-1 fonts,
we no
longer need to distribute t
Hi Ian,
I haven't actually tested this patch, but here are a few comments.
http://codereview.appspot.com/736041/diff/1/5
File scm/lily.scm (right):
http://codereview.appspot.com/736041/diff/1/5#newcode262
scm/lily.scm:262:
I removed this 'gettext wrapper because LilyPond only supports Guile
1.
LGTM.
Thanks,
Patrick
http://codereview.appspot.com/931041/show
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2010/04/19 21:13:14, Neil Puttock wrote:
On 2010/04/19 19:37:12, Carl wrote:
> Should the name of this property be something like
ignore-prefatory-material?
Actually, I've had a thought: instead of using booleans, it would
probably make
more sense (and allow finer control) to use a pai
Reviewers: Neil Puttock,
http://codereview.appspot.com/956051/diff/1/3
File lily/slur-scoring.cc (right):
http://codereview.appspot.com/956051/diff/1/3#newcode86
lily/slur-scoring.cc:86: Slur_score_state::slur_direction (Grob *me)
const
On 2010/04/29 22:40:10, Neil Puttock wrote:
Do you need t
http://codereview.appspot.com/1428042/diff/13002/17014
File configure.in (right):
http://codereview.appspot.com/1428042/diff/13002/17014#newcode140
configure.in:140: STEPMAKE_PATH_PROG(FONTFORGE, fontforge, REQUIRED,
20090923)
Is 20090923 actually required?
I didn't want to bump the required fo
Hi Joe,
From what I can tell, LGTM. `make check' is okay, and I can't reproduce
the erroneous offset anymore.
http://codereview.appspot.com/1694041/show
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lily
http://codereview.appspot.com/1428042/diff/34001/35011
File scm/framework-svg.scm (right):
http://codereview.appspot.com/1428042/diff/34001/35011#newcode138
scm/framework-svg.scm:138: (dump (svg-end))
Adding the following code fixes the memory leak Neil refers to, though
there might be a better
Just a few more comments...
http://codereview.appspot.com/1428042/diff/34001/35014
File scm/output-svg.scm (right):
http://codereview.appspot.com/1428042/diff/34001/35014#newcode25
scm/output-svg.scm:25: ;;; set by framework-gnome.scm
;;; set by framework-svg.scm
http://codereview.appspot.com/
On 2010/06/17 20:04:53, Neil Puttock wrote:
On 2010/06/17 19:49:26, Patrick McCarty wrote:
> Adding the following code fixes the memory leak Neil refers to,
though there
> might be a better way.
>
> (if (ly:get-option 'svg-woff)
> (module-define! (ly:outputter-module outputter) 'paper #f
Thanks for working on this, Neil. Just one quick comment, and
otherwise, LGTM.
http://codereview.appspot.com/931041/diff/14001/15007
File scm/define-grob-properties.scm (right):
http://codereview.appspot.com/931041/diff/14001/15007#newcode757
scm/define-grob-properties.scm:757: multi-measure r
Hi Mike,
This is very impressive. Thanks for your work on this. I just have a
few comments for you about the SVG-related code.
Thanks,
Patrick
http://codereview.appspot.com/1425041/diff/12001/13007
File scm/lily-library.scm (right):
http://codereview.appspot.com/1425041/diff/12001/13007#new
Reviewers: carl.d.sorensen_gmail.com,
Message:
Thanks Carl.
I'll be uploading a new patch shortly.
-Patrick
http://codereview.appspot.com/1730044/diff/1/2
File scm/define-markup-commands.scm (right):
http://codereview.appspot.com/1730044/diff/1/2#newcode622
scm/define-markup-commands.scm:622
On 2010/06/22 03:50:24, Carl wrote:
On 2010/06/21 22:39:53, Patrick McCarty wrote:
> On 2010/06/20 11:07:37, Carl wrote:
> > Is it possible to have the path command estimate reasonable
> > extents, rather than using (0 . 0) and (0 . 0)? Since we
> > know the thickness of the line, and we have a
On 2010/06/29 23:58:07, Neil Puttock wrote:
Do you think the property name's OK though? I agree with Carl it
could be a bit
more descriptive, but then there's also the need to keep verbosity to
a minimum.
Yes, I think the property name is fine.
-Patrick
http://codereview.appspot.com/93104
I am currently working on integrating my work with Mike's new stencil
routines, so I'll post a new patch when that's ready.
Jan: I like your idea about using a separate module to evaluate the
various commands, though IIUC, this would be duplicating the work done
by the backend "path" procedures i
Hi all,
This patchset integrates some of Mike's work in order to fix the stencil
extents for paths and to combine some duplicate functionality.
Thanks,
Patrick
http://codereview.appspot.com/1730044/show
___
lilypond-devel mailing list
lilypond-devel@
Thanks Carl. I'll upload my changes shortly.
-Patrick
http://codereview.appspot.com/1730044/diff/35001/36003
File scm/define-stencil-commands.scm (left):
http://codereview.appspot.com/1730044/diff/35001/36003#oldcode30
scm/define-stencil-commands.scm:30: connected-shape
On 2010/07/28 19:08:16
Hi Ian,
On 2010/07/28 22:49:11, Ian Hulin wrote:
On 19/05/10 23:42, mailto:n.putt...@gmail.com wrote:
>
> I've tried testing your latest patch, but it fails on
clip-systems.ly.
>
> `make-rhythmic-location' (defined in clip-region.scm) appears to be
> inaccessible from a \layout block.
A new
On 2010/07/29 00:28:24, Patrick McCarty wrote:
On 2010/07/28 22:49:11, Ian Hulin wrote:
> On 19/05/10 23:42, mailto:n.putt...@gmail.com wrote:
> >
> > I've tried testing your latest patch, but it fails on
clip-systems.ly.
> >
> > `make-rhythmic-location' (defined in clip-region.scm) appears to
se though...
Processing
`/home/pnorcks/git/lilypond/ly/generate-documentation.ly'/home/pnorcks/git/lilypond/out/share/lilypond/current/scm/lily.scmBacktrace:
In ice-9/boot-9.scm:
170: 14 [catch #t # ...]
In unknown file:
?: 13 [catch-closure]
In /home/pnorcks/git/lilypond/scm/lily.scm:
http://www.codereview.appspot.com/1160044/diff/51001/52005
File scm/lily.scm (right):
http://www.codereview.appspot.com/1160044/diff/51001/52005#newcode215
scm/lily.scm:215: (apply fancy-format (cons dest . rest
`cons' only works with two concrete arguments, like
(cons dest rest)
http://
http://www.codereview.appspot.com/1160044/diff/51001/52003
File lily/ly-module.cc (right):
http://www.codereview.appspot.com/1160044/diff/51001/52003#newcode46
lily/ly-module.cc:46: Guile V1.9/2.0
On 2010/08/09 19:08:58, Neil Puttock wrote:
Is it?
I don't know. But I did file a bug report re
On 2010/08/13 11:04:00, Carl wrote:
LGTM.
Carl
Thanks Carl.
I'll push this patchset shortly (with regression tests).
-Patrick
http://codereview.appspot.com/1730044/show
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org
On 2010/08/28 19:16:18, Ian Hulin wrote:
Patrick and Neil, do I have to fix all the compatibility
problems in all the scm files loaded by lily.scm in order
to push what we have so far?
No. Some of the other compatibility problems are quite complicated and
deserve their own separate issues.
P
Hi Ian,
Looks good mostly, though I haven't compiled anything yet. I just have
a few comments for you.
Thanks,
Patrick
http://codereview.appspot.com/2204044/diff/7001/flower/include/guile-compatibility.hh
File flower/include/guile-compatibility.hh (right):
http://codereview.appspot.com/22040
Ian,
One more thing: There are two more instances of scm_int2num in
lily/dispatcher.cc that you can replace with scm_from_int.
Thanks,
Patrick
http://codereview.appspot.com/2204044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.
On 2010/09/26 10:19:59, ianhulin44 wrote:
On 2010/09/26 00:00:27, Neil Puttock wrote:
>
> Why is that useful? It's irrelevant for anybody using 1.8.
--verbose messages are used for development and maintenance purposes
as well as
for advanced user hacking.
Yes.
E.g. messages are output f
Hi Ian,
Just a few more comments for you.
I am okay with using scm_to_uint(); that looks like a safe route for us
to take.
Thanks,
Patrick
http://codereview.appspot.com/2204044/diff/14001/flower/include/guile-compatibility.hh
File flower/include/guile-compatibility.hh (right):
http://coderev
http://codereview.appspot.com/2313044/diff/1/scm/ly-syntax-constructors.scm
File scm/ly-syntax-constructors.scm (left):
http://codereview.appspot.com/2313044/diff/1/scm/ly-syntax-constructors.scm#oldcode20
scm/ly-syntax-constructors.scm:20: (define define-ly-syntax
define-public)
Instead of remo
Hi Neil,
Looks great!
I just have a couple of comments for you (below).
Thanks,
Patrick
http://codereview.appspot.com/2275042/diff/2001/input/regression/stencil-scale.ly
File input/regression/stencil-scale.ly (right):
http://codereview.appspot.com/2275042/diff/2001/input/regression/stencil-s
On 2010/10/09 15:31:14, ianhulin44 wrote:
On 2010/10/08 05:00:00, Patrick McCarty wrote:
> scm/ly-syntax-constructors.scm:20: (define define-ly-syntax
> define-public)
>
> Instead of removing this definition (like I did), would it be
> possible to use a macro here? Something like
>
> (defma
LGTM.
Ian, please send me the git patch, and I'll apply it for you.
Thanks,
Patrick
http://codereview.appspot.com/2204044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Hi Ian,
I will test your patch shortly.
Thanks,
Patrick
http://codereview.appspot.com/2219044/diff/15001/scm/lily.scm
File scm/lily.scm (right):
http://codereview.appspot.com/2219044/diff/15001/scm/lily.scm#newcode231
scm/lily.scm:231: (_ "Guile 1.8\n")
Okay, I can live with this. :)
ht
ntext:
;;; compiling
/home/pnorcks/usr/share/lilypond/2.13.37/scm/music-functions.scm
;;; compiling
/home/pnorcks/usr/share/lilypond/2.13.37/scm/display-lily.scm
;;; WARNING: compilation of
/home/pnorcks/usr/share/lilypond/2.13.37/scm/display-lily.scm failed:
;;; key syntax-error, throw args (macroexpand &quo
http://codereview.appspot.com/2699041/diff/9001/input/regression/note-names.ly
File input/regression/note-names.ly (right):
http://codereview.appspot.com/2699041/diff/9001/input/regression/note-names.ly#newcode8
input/regression/note-names.ly:8: \version "2.13.37"
I prefer having \version statem
LGTM.
Thanks,
Patrick
http://codereview.appspot.com/2275042/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Looks pretty good to me. Just a tiny style nitpick indicated below.
Thanks for your work on this!
Regards,
Patrick
http://codereview.appspot.com/2699041/diff/33001/input/regression/note-names.ly
File input/regression/note-names.ly (right):
http://codereview.appspot.com/2699041/diff/33001/inp
compiling
/home/pnorcks/usr/share/lilypond/2.13.39/scm/music-functions.scm
;;; compiling
/home/pnorcks/usr/share/lilypond/2.13.39/scm/display-lily.scm
;;; WARNING: compilation of
/home/pnorcks/usr/share/lilypond/2.13.39/scm/display-lily.scm failed:
;;; key syntax-error, throw args (macroexpand &quo
Hi Ian,
I found a rebasing issue that should be sorted out, as explained in my
comment below.
Also, I think the subject line of this patch can be improved, since
we're no longer removing `define-ly-syntax', just revising it.
Thanks,
Patrick
http://codereview.appspot.com/2313044/diff/7001/scm/
Hi Ian,
Just about there... Three lines with whitespace issues, and then
everything should be ready to go.
Thanks,
Patrick
http://codereview.appspot.com/2313044/diff/20001/scm/ly-syntax-constructors.scm
File scm/ly-syntax-constructors.scm (right):
http://codereview.appspot.com/2313044/diff/20
Hi Ian,
LGTM.
Before sending me the git patch, I would recommend changing the subject
from "Remove (define define-ly-syntax define-public)" to something more
accurate that reflects what this patch fixes.
Thanks for your work on this!
Regards,
Patrick
http://codereview.appspot.com/2313044/
__
Hi Carl,
Just one tiny style nitpick below. Otherwise, looks fine.
Thanks,
Patrick
http://codereview.appspot.com/3099041/diff/6001/ly/paper-defaults-init.ly
File ly/paper-defaults-init.ly (right):
http://codereview.appspot.com/3099041/diff/6001/ly/paper-defaults-init.ly#newcode60
ly/paper-de
Thanks for your work, Keith.
I tested all of the changed snippets, and I didn't detect any noticeable
differences (besides some spacing improvements).
One question about the commit message: it mentions
"engravers-one-by-one.ly", but there are no changes to this file in your
patch. Should there
Thanks for your work, Keith.
I tested all of the changed snippets, and I didn't detect any noticeable
differences (besides some spacing improvements).
One question about the commit message: it mentions
"engravers-one-by-one.ly", but there are no changes to this file in your
patch. Should there
On 2010/11/19 07:02:35, Mark Polesky wrote:
When they ceased to be, the functionality
they provided was presumably achievable using the new
spacing alists, but a convert-ly rule to automate this was
never written.
IIUC, this would not be a straightforward conversion that regular
expressions can
On 2010/11/19 17:26:49, Mark Polesky wrote:
On 2010/11/19 07:55:46, Patrick McCarty wrote:
> I would suggest a NOT SMART rule that recommends the
> use of the new spacing alists.
At which release point should this rule be entered? This
commit was pushed 2.13.4:
2f38710 Rewrite the vertical la
On 2010/11/19 10:06:33, perpeduumimmobile wrote:
On 2010/11/19 07:55:46, Patrick McCarty wrote:
> IIUC, this would not be a straightforward conversion that regular
> expressions can (easily) deal with. I would suggest a NOT SMART
> rule that recommends the use of the new spacing alists.
I sec
Hi Ian,
On 2010/11/25 15:56:26, ianhulin44 wrote:
Another thought re the conditional (define-module) idea, if it's
(if) making the guile compilation barf, we could try using
(cond) or (cond-expand) instead.
I just tried all of these options, and nothing seems to work. I'm
pretty baffled.
In
Hi Carl,
The code looks good.
The patch's subject should have "1428" though, not "1248".
Thanks,
Patrick
http://codereview.appspot.com/3416045/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-dev
LGTM
http://codereview.appspot.com/6458159/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
http://codereview.appspot.com/6496074/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2012/09/03 05:39:57, dak wrote:
On 2012/09/03 03:41:39, Patrick McCarty wrote:
> LGTM
Let's not get this merged. ly_lily_module_constant
("module-variable") is
available in _both_ Guile 1.8 as well as Guile 2.0.
Thanks for mentioning this; I didn't recall the Scheme procedure being
ava
LGTM
https://codereview.appspot.com/5504106/diff/1/scm/output-ps.scm
File scm/output-ps.scm (right):
https://codereview.appspot.com/5504106/diff/1/scm/output-ps.scm#newcode258
scm/output-ps.scm:258: (define (open-node n) n)
I don't see this procedure used anywhere...
https://codereview.appspot
http://codereview.appspot.com/4172047/diff/1/scm/define-markup-commands.scm
File scm/define-markup-commands.scm (right):
http://codereview.appspot.com/4172047/diff/1/scm/define-markup-commands.scm#newcode1033
scm/define-markup-commands.scm:1033: #:with-dimensions (cons 0
middle-width) '(0 . 0) #
Hi Ian,
Please see my new comment regarding this patch (below).
Thanks,
Patrick
http://codereview.appspot.com/2219044/diff/25001/scm/display-lily.scm
File scm/display-lily.scm (right):
http://codereview.appspot.com/2219044/diff/25001/scm/display-lily.scm#newcode34
scm/display-lily.scm:34:
Jan
http://codereview.appspot.com/2219044/diff/25001/scm/display-lily.scm
File scm/display-lily.scm (right):
http://codereview.appspot.com/2219044/diff/25001/scm/display-lily.scm#newcode34
scm/display-lily.scm:34:
On 2011/02/17 15:07:00, ianhulin44 wrote:
In which case, do we even need lily.scm to
On 2011/02/17 17:05:25, Reinhold wrote:
http://codereview.appspot.com/2219044/diff/25001/scm/display-lily.scm
File scm/display-lily.scm (right):
http://codereview.appspot.com/2219044/diff/25001/scm/display-lily.scm#newcode34
scm/display-lily.scm:34:
> We are in musicxml2ly and a few snippe
LGTM.
Can you email me your patch so I can apply it?
Thanks,
Patrick
http://codereview.appspot.com/2219044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Hi Boris,
Just a code nitpick (in two places).
Please remember to Cc: lilypond-devel for Rietveld patches so that we
know code review is taking place.
Thanks,
Patrick
http://codereview.appspot.com/4236047/diff/1/lily/paper-book.cc
File lily/paper-book.cc (right):
http://codereview.appspot.co
Hi Mike,
I have a quick comment for you below.
Thanks,
Patrick
http://codereview.appspot.com/4213042/diff/24035/scm/define-stencil-commands.scm
File scm/define-stencil-commands.scm (right):
http://codereview.appspot.com/4213042/diff/24035/scm/define-stencil-commands.scm#newcode37
scm/define-s
The load-order issue appears to be fixed, testing with git and guile 1.8
and 2.0.2. Ignoring whitespace changes, this patch LGTM.
Some more shuffling is needed to make sure we have markup commands
defined where they need to be, but that's beyond the scope of this
patch.
Thanks,
Patrick
https:/
Reviewers: Reinhold,
Message:
I would recommend making the small change that's explained in the
comment.
Thanks,
Patrick
http://codereview.appspot.com/11851/diff/1/2
File lilypond-texi2html.init (right):
http://codereview.appspot.com/11851/diff/1/2#newcode669
Line 669: print $fh "[...]
Other
82 matches
Mail list logo
