Please read my suggested changes carefully and amend, as I've no
knowledge of the subject matter.
https://codereview.appspot.com/577900043/diff/577910043/Documentation/usage/running.itely
File Documentation/usage/running.itely (right):
https://codereview.appspot.com/577900043/diff/577910043/Docu
Thanks for picking this up and taking it over the finishing line,
Valentin. LGTM apart from a couple of nits.
Trevor
https://codereview.appspot.com/553750044/diff/561590043/Documentation/notation/staff.itely
File Documentation/notation/staff.itely (right):
https://codereview.appspot.com/5537500
LGTM
Trevor
https://codereview.appspot.com/583340043/
LGTM
Trevor
https://codereview.appspot.com/548590043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
The proposed documentation looks fine to me.
Trevor
https://codereview.appspot.com/346810043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
https://codereview.appspot.com/343060043/diff/20001/Documentation/learning/fundamental.itely
File Documentation/learning/fundamental.itely (right):
https://codereview.appspot.com/343060043/diff/20001/Documentation/learning/fundamental.itely#newcode495
Documentation/learning/fundamental.itely:495
Hi Carl
Another minor nit! Otherwise looks fine.
Trevor
https://codereview.appspot.com/343060043/diff/20001/Documentation/learning/fundamental.itely
File Documentation/learning/fundamental.itely (right):
https://codereview.appspot.com/343060043/diff/20001/Documentation/learning/fundamental.
Hi Carl
LGTM, with a couple of minor comments.
Trevor
https://codereview.appspot.com/343060043/diff/1/Documentation/learning/fundamental.itely
File Documentation/learning/fundamental.itely (right):
https://codereview.appspot.com/343060043/diff/1/Documentation/learning/fundamental.itely#newco
https://codereview.appspot.com/336030043/diff/1/Documentation/notation/rhythms.itely
File Documentation/notation/rhythms.itely (right):
https://codereview.appspot.com/336030043/diff/1/Documentation/notation/rhythms.itely#newcode93
Documentation/notation/rhythms.itely:93: music sequence will take
Apart from a duplicated para this LGTM.
Trevor
https://codereview.appspot.com/336030043/diff/1/Documentation/notation/rhythms.itely
File Documentation/notation/rhythms.itely (right):
https://codereview.appspot.com/336030043/diff/1/Documentation/notation/rhythms.itely#newcode93
Documentation/no
Looks OK as far as it goes, but the Docs have been missed.
Trevor
https://codereview.appspot.com/323040043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2017/05/21 17:12:26, thomasmorley651 wrote:
I'd like to mention another point:
What to do with pitched rests and rests with user-set staff-position,
merge them
automatically to the zero-position?
If a user has explicitly set the position of a rest this should be
honoured
by default, I thin
LGTM
David, you've found an excellent way of squaring the circle!
Trevor
https://codereview.appspot.com/320820043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
Trevor
https://codereview.appspot.com/312540043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM, apart from a minor nit.
As Phil says - no need to wait for a review cycle.
https://codereview.appspot.com/320180043/diff/1/Documentation/contributor/quick-start.itexi
File Documentation/contributor/quick-start.itexi (right):
https://codereview.appspot.com/320180043/diff/1/Documentation/c
LGTM
Trevor
https://codereview.appspot.com/314390043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
Trevor
https://codereview.appspot.com/319940043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM, with the trivial suggestions indicated below to the NR, but I'm
not competent to check the code sections.
The use of "__" has been expunged completely: should we not retain a
brief mention perhaps for use when the user has turned auto extenders
off?
Trevor
https://codereview.appspot.co
Much improved over the first attempt, thanks. LGTM.
Trevor
https://codereview.appspot.com/302930043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
Trevor
https://codereview.appspot.com/304810043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
Trevor
https://codereview.appspot.com/299510043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Excellent!
I've wanted to do this for years, but lacked the scripting skills to do
it.
Trevor
https://codereview.appspot.com/295570043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
See below. LGTM now.
Trevor
https://codereview.appspot.com/294820044/diff/1/Documentation/contributor/issues.itexi
File Documentation/contributor/issues.itexi (right):
https://codereview.appspot.com/294820044/diff/1/Documentation/contributor/issues.itexi#newcode1021
Documentation/contributor
New stuff looks OK, but I'm concerned about the deleted section.
https://codereview.appspot.com/294820044/diff/1/Documentation/contributor/issues.itexi
File Documentation/contributor/issues.itexi (right):
https://codereview.appspot.com/294820044/diff/1/Documentation/contributor/issues.itexi#new
On 2015/12/22 18:34:43, git wrote:
https://codereview.appspot.com/276560043/diff/20001/Documentation/snippets/subdividing-beams.ly
File Documentation/snippets/subdividing-beams.ly (right):
https://codereview.appspot.com/276560043/diff/20001/Documentation/snippets/subdividing-beams.ly#newcode7
LGTM, apart from a pre-existing typo.
https://codereview.appspot.com/280940043/diff/1/Documentation/notation/simultaneous.itely
File Documentation/notation/simultaneous.itely (right):
https://codereview.appspot.com/280940043/diff/1/Documentation/notation/simultaneous.itely#newcode1030
Documenta
LGTM
When this is pushed we ought to raise an issue to document whiteout
properly in the NR.
https://codereview.appspot.com/274590043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
https://codereview.appspot.com/275490043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Much clearer, James. LGTM, apart from a couple of nits.
https://codereview.appspot.com/276980044/diff/1/Documentation/contributor/administration.itexi
File Documentation/contributor/administration.itexi (right):
https://codereview.appspot.com/276980044/diff/1/Documentation/contributor/administ
LGTM
https://codereview.appspot.com/278060043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM, apart from an oversight, although this is based on just
eye-balling.
https://codereview.appspot.com/270640043/diff/11/scm/define-markup-commands.scm
File scm/define-markup-commands.scm (right):
https://codereview.appspot.com/270640043/diff/11/scm/define-markup-commands.scm#newcod
LGTM
https://codereview.appspot.com/277940043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
https://codereview.appspot.com/270640043/diff/60001/scm/define-markup-commands.scm#newcode623
> > scm/define-markup-commands.scm:623: (direction DOWN)
> > Should this markup command be called "undertie" or should it
rather be
"tie",
> > with "undertie" explicitly overriding `direction'?
> >
>
I can't vouch for the technicalities, but LGTM apart from a few typos.
https://codereview.appspot.com/274260043/diff/40001/Documentation/usage/running.itely
File Documentation/usage/running.itely (right):
https://codereview.appspot.com/274260043/diff/40001/Documentation/usage/running.itely#newc
I raise a couple of questions - maybe I'm not understanding something.
https://codereview.appspot.com/275770043/diff/1/scm/define-grob-properties.scm
File scm/define-grob-properties.scm (right):
https://codereview.appspot.com/275770043/diff/1/scm/define-grob-properties.scm#newcode1143
scm/defin
https://codereview.appspot.com/265410043/diff/60001/lily/part-combine-iterator.cc
File lily/part-combine-iterator.cc (right):
https://codereview.appspot.com/265410043/diff/60001/lily/part-combine-iterator.cc#newcode146
lily/part-combine-iterator.cc:146: // get_event_length(), which reads
"length
LGTM
https://codereview.appspot.com/268050045/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Not being overly familiar with *nix I can't vouch for the technicalities
and syntax, but the general text looks fine (apart from a couple of
trivial typos). So LGTM.
https://codereview.appspot.com/261430043/diff/1/Documentation/included/compile.itexi
File Documentation/included/compile.itexi (
LGTM
https://codereview.appspot.com/266960043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
You don't appear to have changed the menus in the translations, but I
would strongly recommend leaving all the translations to the translators
- unless you can translate the modified headings into Czech and
Japanese.
https://codereview.appspot.com/261240043/diff/20001/Documentation/usage/running
LGTM
https://codereview.appspot.com/268780043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
https://codereview.appspot.com/258680043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
https://codereview.appspot.com/258660043/diff/1/Documentation/included/authors.itexi
File Documentation/included/authors.itexi (left):
https://codereview.appspot.com/258660043/diff/1/Documentation/included/authors.itexi#oldcode199
Documentation/included/authors.itexi:199: Abraham Lee
I think Abr
LGTM
Trevor
https://codereview.appspot.com/259710043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2015/08/11 11:25:23, dak wrote:
On 2015/08/11 10:48:24, Trevor Daniels wrote:
>
https://codereview.appspot.com/257280043/diff/1/Documentation/notation/spacing.itely
> File Documentation/notation/spacing.itely (right):
>
>
https://codereview.appspot.com/257280043/diff/1/Documentation/notat
https://codereview.appspot.com/257280043/diff/1/Documentation/notation/spacing.itely
File Documentation/notation/spacing.itely (right):
https://codereview.appspot.com/257280043/diff/1/Documentation/notation/spacing.itely#newcode383
Documentation/notation/spacing.itely:383: @code{ragged-last-bott
https://codereview.appspot.com/257280043/diff/1/Documentation/notation/spacing.itely
File Documentation/notation/spacing.itely (right):
https://codereview.appspot.com/257280043/diff/1/Documentation/notation/spacing.itely#newcode383
Documentation/notation/spacing.itely:383: @code{ragged-last-bott
https://codereview.appspot.com/259130043/diff/20001/Documentation/usage/external.itely
File Documentation/usage/external.itely (right):
https://codereview.appspot.com/259130043/diff/20001/Documentation/usage/external.itely#newcode780
Documentation/usage/external.itely:780: @rweb{Easier editing}
Reviewers: ,
https://codereview.appspot.com/256340043/diff/1/input/regression/ssaattbb-template-with-changed-instrument-names.ly
File input/regression/ssaattbb-template-with-changed-instrument-names.ly
(left):
https://codereview.appspot.com/256340043/diff/1/input/regression/ssaattbb-template-wi
LTGM
Trevor
https://codereview.appspot.com/255570043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Apart from nitpicking, doc changes LGTM
Trevor
https://codereview.appspot.com/256990043/diff/20001/Documentation/notation/changing-defaults.itely
File Documentation/notation/changing-defaults.itely (right):
https://codereview.appspot.com/256990043/diff/20001/Documentation/notation/changing-de
LGTM, apart from a trivial typo.
Trevor
https://codereview.appspot.com/254370043/diff/1/Documentation/contributor/issues.itexi
File Documentation/contributor/issues.itexi (right):
https://codereview.appspot.com/254370043/diff/1/Documentation/contributor/issues.itexi#newcode22
Documentation/co
LGTM
Trevor
https://codereview.appspot.com/256090043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
https://codereview.appspot.com/250530043/diff/1/Documentation/notation/repeats.itely
File Documentation/notation/repeats.itely (right):
https://codereview.appspot.com/250530043/diff/1/Documentation/notation/repeats.itely#newcode764
Documentation/notation/repeats.itely:764: @knownissues
@knowniss
https://codereview.appspot.com/255280043/diff/1/Documentation/usage/external.itely
File Documentation/usage/external.itely (right):
https://codereview.appspot.com/255280043/diff/1/Documentation/usage/external.itely#newcode726
Documentation/usage/external.itely:726: OpenOffice.org extension that
Thanks David
https://codereview.appspot.com/253310043/diff/1/ly/staff-tkit.ly
File ly/staff-tkit.ly (right):
https://codereview.appspot.com/253310043/diff/1/ly/staff-tkit.ly#newcode60
ly/staff-tkit.ly:60: #(if dynUp
On 2015/07/18 22:02:54, dak wrote:
elseif cascades are bad to read in Scheme's
If I understand this correctly it permits a variable definition to be
used in some circumstances where a music function definition would
previously have been required to achieve the same effect. That seems a
worthwhile improvement and simplification.
Trevor
https://codereview.appspot.com/24967
Reviewers: Keith,
https://codereview.appspot.com/249980043/diff/1/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):
https://codereview.appspot.com/249980043/diff/1/Documentation/notation/input.itely#newcode3279
Documentation/notation/input.itely:3279: @ref{MIDI
On balance the indentation is improved, but there are a few cases which
are worse, IMHO. With a follow-up hand-indentation to "uncorrect" the
worst cases this would be worth doing, if just to remove the tabs.
Trevor
https://codereview.appspot.com/249270044/diff/1/input/regression/alignment-ve
LGTM
Trevor
https://codereview.appspot.com/252770043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
Thanks Keith
https://codereview.appspot.com/237340043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
I'm generally happy with this, but I've made quite a few nit-picking
comments. I think it is important that the manuals rigorously show a
consistent style, particularly with regard to indentation and the
placement of block delimiters. We frequently criticise users presenting
examples on the mail
Just querying a strange sentence.
https://codereview.appspot.com/244840043/diff/11/Documentation/changes.tely
File Documentation/changes.tely (right):
https://codereview.appspot.com/244840043/diff/11/Documentation/changes.tely#newcode69
Documentation/changes.tely:69: matching based will
Well, I can't say LGTM as that would imply I'd understood it and could
confirm its correctness, but I can say I'm looking forward to removing
lots of the #{ ... #} in the satb.ly template and its supporting cast!
Trevor
https://codereview.appspot.com/244840043/
Apart from a really trivial nitpick, LGTM
(but I haven't checked if anything has been missed)
Trevor
https://codereview.appspot.com/239250043/diff/1/Documentation/notation/pitches.itely
File Documentation/notation/pitches.itely (right):
https://codereview.appspot.com/239250043/diff/1/Document
LGTM
Trevor
https://codereview.appspot.com/240810043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2015/05/17 21:09:13, dak wrote:
At any rate, if we were to retain both \fixed and \absolute,
I strongly prefer just two input modes, \relative and \absolute, but
as I said right at the beginning:
... I'd prefer
the syntax and options [of \absolute] to parallel those of
\relative. That
I'm not opposed to the change to explicit \relative; it avoids having to
explain why it was omitted in the examples, and makes the example code
more exactly correspond to the code obtained by clicking on the image.
But I think if are to make this change it would also be good to say what
leaving ou
On 2015/05/17 10:44:36, dak wrote:
Well, I remain unenthused about the new name. Maybe get a vote on the
user
list, with options \absolute x'', \fixed x'', \octave x''? I think
those were
pretty much the terms mentioned significantly more than once.
The proper name for this would \absolu
On 2015/05/17 07:36:01, Keith wrote:
On 2015/05/15 06:12:38, lemzwerg wrote:
> Given that we are currently producing development
> releases, I suggest that this gets implemented,
> then we simply wait a few months so that people can
> test it in real life, and then we do a final decision.
If w
On 2015/05/06 15:57:21, wl_gnu.org wrote:
> Probably the best name is \octave, which was used for something
> similar
> until version 0.1.19
>
> \octave c'' {c4 e g c e g c'1}
Sounds OK for me.
Werner
So is this proposing three entry modes:
\relative (unchanged)
\absolute
I haven't checked incipit.ly, but otherwise it looks fine apart from
what appears to be an inadvertent change which needs investigating.
https://codereview.appspot.com/235980043/diff/1/Documentation/snippets/conducting-signs,-measure-grouping-signs.ly
File Documentation/snippets/conducting-signs
On 2015/05/05 12:07:32, mail_philholmes.net wrote:
I read the CG on *index entries, and experimented a fair amount, but
never
quite got to understand the difference.
Is cindex the Command index only? Should it be @cindex \incipit or
@cindex
incipit? Or both? And funindex is the main ind
One suggestion, otherwise LGTM.
https://codereview.appspot.com/232180043/diff/1/Documentation/notation/ancient.itely
File Documentation/notation/ancient.itely (right):
https://codereview.appspot.com/232180043/diff/1/Documentation/notation/ancient.itely#newcode2651
Documentation/notation/ancient
On 2015/05/03 20:25:22, dak wrote:
Again: I don't think that this was Keith's proposal. And I am pretty
sure that
none of my suggestions was Keith's proposal either: I just angle for
something
useful to do with \absolute f.
It wasn't Keith's proposal, you're right, I rather ran on ahead.
On 2015/05/03 09:02:51, dak wrote:
However, I _think_ that your comment would suggest \absolute f'' { f
... to be
the same
as \absolute { f'' ...
Correct
whereas I suggested making \absolute f'' { f ... the same
as \absolute { bes'' ...
Now there _is_ a difference between \relative c an
LGTM.
Trevor
https://codereview.appspot.com/233110043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
Trevor
https://codereview.appspot.com/235920043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Good point, Phil. Perhaps we should slightly amend the text too to
cover this feature, as shown.
Trevor
https://codereview.appspot.com/233110043/diff/20001/Documentation/notation/simultaneous.itely
File Documentation/notation/simultaneous.itely (right):
https://codereview.appspot.com/2331100
I'm in favour of a change like this, but I'd prefer
the syntax and options to parallel those of
\relative. That is, an optional prefix pitch to indicate
the starting octave, and taking the starting octave from
the first contained note if the prefix is omitted. That
would then become an attractiv
https://codereview.appspot.com/233110043/diff/1/Documentation/notation/simultaneous.itely
File Documentation/notation/simultaneous.itely (right):
https://codereview.appspot.com/233110043/diff/1/Documentation/notation/simultaneous.itely#newcode931
Documentation/notation/simultaneous.itely:931: @n
Hi James
I'm happy with this now. Thanks for being so forbearing and persistent
in the face of all the criticism. So, LGTM!
Trevor
https://codereview.appspot.com/120480043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.o
Reviewers: Jean-Charles,
https://codereview.appspot.com/227470043/diff/1/Documentation/learning/fundamental.itely
File Documentation/learning/fundamental.itely (right):
https://codereview.appspot.com/227470043/diff/1/Documentation/learning/fundamental.itely#newcode3193
Documentation/learning/fu
I can't compile LP at the moment, but LGTM from eye-balling. How
pleasing it took just two extra lines!
Trevor
https://codereview.appspot.com/226700043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/li
On 2015/04/21 19:58:34, dak wrote:
Is Women/Men the correct nomenclature or would it rather be
female/male [voice
types]? As an alto I'd prefer the least sexist designation as long as
it
matches typical usage.
"Men" is commonly seen in vocal scores, certainly in Oxford and Novello
publica
On 2015/04/20 16:31:52, J_lowe wrote:
https://codereview.appspot.com/120480043/diff/240001/Documentation/notation/input.itely#newcode2732
Documentation/notation/input.itely:2732: accent, marcato and portato.
On 2014/12/28 23:40:29, Trevor Daniels wrote:
> We need a proper list here showing clea
On 2015/04/18 15:30:06, Trevor Daniels wrote:
Fix file names of two more regression tests
Sorry for the extra work James. Three out of four regression tests had
missing hyphens! Windows, perhaps unfortunately, is quite happy with
file names containing spaces, so I saw no errors here.
Trevor
Patch set 2 contains a number of code improvements as well as four
regression tests and a (minimal) change to the documentation. The main
changes from patch set 1 are:
- There is now a distinction between Women/Men music variables in their
own right and WomenDivided/MenDivided variables which ar
message: On 2015/04/08 01:54:02, Dan Eble wrote:
Thanks for looking, Dan
To support TTBB, would you generalize this template further, or would
you create
something new?
My intention is to add an ssaattbb template once this patch has been
installed. This would have three staves for each part
Reviewers: ,
Message:
This patch is posted for comment and improvement rather than a candidate
for immediate inclusion in the code base. Some
caveats/issues/questions:
\includes are used for testing; later, perhaps after settling on the
file names, these may not be necessary.
Indenting is prob
LGTM
Trevor
https://codereview.appspot.com/225840043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
https://codereview.appspot.com/222090043/diff/1/scm/define-music-types.scm
File scm/define-music-types.scm (right):
https://codereview.appspot.com/222090043/diff/1/scm/define-music-types.scm#newcode343
scm/define-music-types.scm:343: (types . ())
On 2015/04/01 15:16:07, david.nalesnik wrote:
Sh
Reviewers: ,
Message:
Pushed to staging as
67e08daacdeb384724e18a31597d9d828ac40f51
Closing ...
Description:
Doc: Issue 4309: Clarify the warning about bare durations
Please review this at https://codereview.appspot.com/203640043/
Affected files (+4, -4 lines):
M Documentation/learning/comm
Reviewers: ,
Message:
This patch eliminates virtually all mention of the
\stemUp and \stemDown predefs from the LM. Most of
the uses of these predefs in the NR are sensible, so
I have left untouched the ones in ancient, editorial,
percussion and staff. Apart from the bald mention in
staff, thes
This is definitely an improvement, so LGTM.
(As David mentioned earlier, there seem to be discrepancies between what
one might expect when setting dash-fraction and the actual result, but
this at least makes the documentation self-consistent.)
https://codereview.appspot.com/198150043/
_
LGTM
Trevor
https://codereview.appspot.com/188580043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2015/01/02 00:22:11, J_lowe wrote:
On 2015/01/02 00:09:19, Trevor Daniels wrote:
>
https://codereview.appspot.com/193870043/diff/1/Documentation/included/compile.itexi
> File Documentation/included/compile.itexi (right):
>
>
https://codereview.appspot.com/193870043/diff/1/Documentation/in
https://codereview.appspot.com/193870043/diff/1/Documentation/included/compile.itexi
File Documentation/included/compile.itexi (right):
https://codereview.appspot.com/193870043/diff/1/Documentation/included/compile.itexi#newcode78
Documentation/included/compile.itexi:78: (1.8.8 - version 2.x is
James
We've now had so many iterations of this I'd lost track of where we were
up to with incremental changes and started over. I think much of it is
improved, but some basic information has been lost and/or buried. I've
tried to indicate as clearly (starkly might be more accurate) as
possible
LGTM
Trevor
https://codereview.appspot.com/194770043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
1 - 100 of 556 matches
Mail list logo