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
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
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
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
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.
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
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
LGTM
Trevor
https://codereview.appspot.com/548590043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Typo
http://codereview.appspot.com/885044/diff/1/2
File input/regression/display-lily-tests.ly (right):
http://codereview.appspot.com/885044/diff/1/2#newcode1
input/regression/display-lily-tests.ly:1: \version "2.13.8"
2.13.18
http://codereview.appspot.com/885044/show
___
Mark
I've not examined every change in detail, but I think I've picked out
all the ones I wanted to comment on.
Trevor
http://codereview.appspot.com/1056041/diff/24001/25001
File Documentation/learning/common-notation.itely (right):
http://codereview.appspot.com/1056041/diff/24001/25001#newcode
I'm not particularly opposed to placing this in the
NR, but it's not clear what you are suggesting here.
Do you mean to leave the LM unchanged, or do you intend
to remove or change the corresponding section there?
Also, if it is to go in the NR it needs a separate
section heading. At the moment
With my correction I'm happy with this.
http://codereview.appspot.com/2226045/diff/3001/Documentation/notation/simultaneous.itely
File Documentation/notation/simultaneous.itely (right):
http://codereview.appspot.com/2226045/diff/3001/Documentation/notation/simultaneous.itely#newcode685
Document
Looks a lot clearer to me, Mark, but I can't vouch for the accuracy as
I've never tried to use vertical spacing. If the variable table came
before the keys table giving a top-down approach it would be even
clearer.
Trevor
http://codereview.appspot.com/2316042/
_
Looks ok to me, although I haven't tried committing it.
Let's push it and move on to trying it out. That
might generate more comment.
BTW, I don't see these (old) \paper block variables in
the IR. Are they not there or have I missed them?
It would be useful for anyone starting to adjust
these
LGTM, but we should add power chords to the glossary and reference it
from the @seealso.
Trevor
http://codereview.appspot.com/2686041/diff/5001/Documentation/notation/fretted-strings.itely
File Documentation/notation/fretted-strings.itely (right):
http://codereview.appspot.com/2686041/diff/5001
Looks pretty good, Mark. I've suggested a couple of changes near the
top.
Trevor
http://codereview.appspot.com/2642043/diff/1/Documentation/notation/spacing.itely
File Documentation/notation/spacing.itely (right):
http://codereview.appspot.com/2642043/diff/1/Documentation/notation/spacing.ite
Congratulations, Valentin, you're on to a winner now!
I've no comments to add to those already made.
Trevor
http://codereview.appspot.com/2699041/diff/9001/Documentation/changes.tely
File Documentation/changes.tely (right):
http://codereview.appspot.com/2699041/diff/9001/Documentation/change
Looks OK to me (i.e. it's clear enough for me to understand)
Trevor
http://codereview.appspot.com/2687043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
LBetterTM, except for excessive TODOs
http://codereview.appspot.com/2755041/diff/1/Documentation/notation/world.itely
File Documentation/notation/world.itely (right):
http://codereview.appspot.com/2755041/diff/1/Documentation/notation/world.itely#newcode62
Documentation/notation/world.itely:62:
A few editorial suggestions ... some apply to other similar instances,
which I've not marked.
http://codereview.appspot.com/2755041/diff/10001/Documentation/notation/pitches.itely
File Documentation/notation/pitches.itely (left):
http://codereview.appspot.com/2755041/diff/10001/Documentation/no
Nearly there :)
http://codereview.appspot.com/2755041/diff/22001/Documentation/notation/pitches.itely
File Documentation/notation/pitches.itely (right):
http://codereview.appspot.com/2755041/diff/22001/Documentation/notation/pitches.itely#newcode588
Documentation/notation/pitches.itely:588: Man
I've not reviewed the code but I share Carl's concern about scheme
engravers if there is no way of documenting them in the IR. If the
grobs have any user-servicable properties they must be properly
documented.
Trevor
http://codereview.appspot.com/2191042/
_
Looks OK to me after eyeballing, but not tested.
Trevor
http://codereview.appspot.com/2791041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Looks fine generally, but some editorial changes are needed.
Trevor
http://codereview.appspot.com/2735044/diff/1/Documentation/notation/pitches.itely
File Documentation/notation/pitches.itely (right):
http://codereview.appspot.com/2735044/diff/1/Documentation/notation/pitches.itely#newcode459
OK, it's an improvement so go ahead and push, but "musics" grates so
much I'd definitely have removed it as part of this patch.
http://codereview.appspot.com/2735044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/l
I may be missing something, but doesn't this assume all line spanners
are glissandi?
Trevor
http://codereview.appspot.com/2723043/diff/1/lily/tab-tie-follow-engraver.cc
File lily/tab-tie-follow-engraver.cc (right):
http://codereview.appspot.com/2723043/diff/1/lily/tab-tie-follow-engraver.cc#ne
here's a patch that will make Trevor happy: no
more "musics"! :-)
:)
Looks pretty good to me, apart from a couple of minor rephrasings.
http://codereview.appspot.com/2732043/diff/3001/Documentation/notation/world.itely
File Documentation/notation/world.itely (left):
http://codereview.appspo
Code not checked; and I still don't understand Scheme indentation, but
at least it ought to be consistent.
Trevor
http://codereview.appspot.com/2726043/diff/1/input/regression/cue-clef.ly
File input/regression/cue-clef.ly (right):
http://codereview.appspot.com/2726043/diff/1/input/regression/
LGTM. Thanks!
http://codereview.appspot.com/2732043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
I'm happy with the changes to vocal.itely, although ragged-right could
also be removed in many (maybe all) of the @lilyponds.
Trevor
http://codereview.appspot.com/2810041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mai
I've limited my comments to just one :) I think we need to push this
now and move on - we still have to change all the names, and a further
review of the wording after that might suggest a few more tweaks. I'm
sure more clarification will be necessary after users try to understand
and use this,
LGTM; just a minor typo and a suggestion to remove inadvisable code.
http://codereview.appspot.com/2642043/diff/14001/Documentation/notation/spacing.itely
File Documentation/notation/spacing.itely (right):
http://codereview.appspot.com/2642043/diff/14001/Documentation/notation/spacing.itely#new
In general I agree with Carl's comments. I've suggested in a couple of
places where I'd like to see the IR material truncated. The full
description of the properties should go in the NR, perhaps in an
appendix if you think it's too technical.
http://codereview.appspot.com/3031041/diff/30001/Do
Apart from the placement of the descriptive text in the IR, which I
think is debatable, I agree with Carl's comments.
Thanks again Mark. Every iteration is an improvement. I think we're
nearly there!
Trevor
http://codereview.appspot.com/3031041/diff/40001/lily/axis-group-interface.cc
File l
You're right, Carl. I'd misunderstood how this works.
Trevor
http://codereview.appspot.com/3031041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Looks a lot better. I've indicated one detail. Also the use of the
spacing suffix on property names looks inconsistent to me. I've not
marked these as there may be more outside this patch, but it seems to be
omitted or included fairly randomly. Could you check this out?
Trevor
http://codere
On 2010/11/14 09:47:40, markpolesky_yahoo.com wrote:
I don't follow -- "the use of the spacing suffix on property
names..." Could you explain what you mean by that?
My mistake! I think I must have misread staff-affinity. (I should have
learned by now not to try to review things in 5 minutes
Looks OK to me. Let's go.
Trevor
http://codereview.appspot.com/3089042/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
It looks better. I added a couple of minor comments which I noticed in
passing, but I've not checked any of the detail.
Trevor
http://codereview.appspot.com/2758042/diff/19002/Documentation/notation/spacing.itely
File Documentation/notation/spacing.itely (right):
http://codereview.appspot.com
LGTM
Trevor
http://codereview.appspot.com/2758042/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
http://codereview.appspot.com/3199041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Content looks fine. A few typographical comments.
http://codereview.appspot.com/2758042/diff/35001/Documentation/notation/spacing.itely
File Documentation/notation/spacing.itely (left):
http://codereview.appspot.com/2758042/diff/35001/Documentation/notation/spacing.itely#oldcode793
Documentati
On 2010/11/20 19:34:44, Mark Polesky wrote:
CG says: NR, Installed Files, Snippets, IR.
Is that wrong?
Hhm. Seems like I mis-remembered where Installed Files goes. I'd argue
it's wrong though, if the order is based on easiest to hardest, or on
recommended order of reference - that's why I tho
Looks good to go to me
Trevor
http://codereview.appspot.com/2758042/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
The several legacy language files should also be changed:
ly/english.ly: Legacy file. (see language-init.ly)
http://codereview.appspot.com/3247041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypo
LGTM
Trevor
http://codereview.appspot.com/3247041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM; just a few nitpicks
http://codereview.appspot.com/3406041/diff/6001/Documentation/notation/spacing.itely
File Documentation/notation/spacing.itely (right):
http://codereview.appspot.com/3406041/diff/6001/Documentation/notation/spacing.itely#newcode1297
Documentation/notation/spacing.itely
LGTM, apart from the one typo.
http://codereview.appspot.com/3406041/diff/15001/Documentation/notation/spacing.itely
File Documentation/notation/spacing.itely (right):
http://codereview.appspot.com/3406041/diff/15001/Documentation/notation/spacing.itely#newcode1212
Documentation/notation/spacin
Looks fine to me.
http://codereview.appspot.com/3581041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Like Carl, I'm happy to approve this as it is, but I'd prefer to see a
comprehensive and correct explanation of the effect of inserting code
between alternatives.
http://codereview.appspot.com/3705042/diff/1/Documentation/learning/fundamental.itely
File Documentation/learning/fundamental.itely (
Just a few comments after eye-balling the patch. I'll need to download
and compile to comment more fully.
http://codereview.appspot.com/3667041/diff/13001/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):
http://codereview.appspot.com/3667041/diff/13001/Docume
I've looked at the compiled version now. It's nicely written, but my
concern is that this is no longer written in 'reference' style. To me,
parts of it seem more suited to the LM. The idea of the NR is that
people already well-familiar with LilyPond can quickly find a keyword or
syntax they hav
Keith
Some of your new material is not in the agreed style the NR, in
particular your attempts to make the examples prettier by inserting \bar
commands. This should not be done without wider agreement to insert
them in all the examples - a change I would oppose as I believe the code
in the examp
LGTM
Trevor
http://codereview.appspot.com/3792041/diff/1/Documentation/notation/ancient.itely
File Documentation/notation/ancient.itely (right):
http://codereview.appspot.com/3792041/diff/1/Documentation/notation/ancient.itely#newcode1355
Documentation/notation/ancient.itely:1355: @ref{Articul
Missed this earlier
http://codereview.appspot.com/3732046/diff/1/Documentation/notation/expressive.itely
File Documentation/notation/expressive.itely (right):
http://codereview.appspot.com/3732046/diff/1/Documentation/notation/expressive.itely#newcode390
Documentation/notation/expressive.itely:
Looks fine to me, but then you've used the wording I suggested, so it
would, wouldn't it :) Best wait for someone else to approve.
Trevor
http://codereview.appspot.com/3705042/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.
Hi James
I think a further change is needed to position the warning in repeats
correctly.
Trevor
http://codereview.appspot.com/3705042/diff/12001/Documentation/notation/repeats.itely
File Documentation/notation/repeats.itely (right):
http://codereview.appspot.com/3705042/diff/12001/Documentat
My comments on the two discussion points below.
http://codereview.appspot.com/3743045/diff/1/Documentation/notation/expressive.itely
File Documentation/notation/expressive.itely (right):
http://codereview.appspot.com/3743045/diff/1/Documentation/notation/expressive.itely#newcode366
Documentatio
On 2010/12/22 12:37:41, pkx166h wrote:
I think that the two 'warning' boxes will look a bit awkward
Maybe, but the placement makes the warning much more relevant. Let's
leave for a couple of days, and if there are no further comments send me
a patch.
http://codereview.appspot.com/3705042/
_
http://codereview.appspot.com/3743045/diff/1/Documentation/notation/expressive.itely
File Documentation/notation/expressive.itely (right):
http://codereview.appspot.com/3743045/diff/1/Documentation/notation/expressive.itely#newcode366
Documentation/notation/expressive.itely:366: Textual crescend
OK, I think we've haggled over this enough :)
Keith, could you please fix the haripins, decide on the wording you
prefer, and let me have a patch to push.
Many thanks.
Trevor
http://codereview.appspot.com/3743045/
___
lilypond-devel mailing list
li
The content looks fine, but it should be rearranged a little to match
the existing style of the documentation.
http://codereview.appspot.com/3782042/diff/1/Documentation/notation/keyboards.itely
File Documentation/notation/keyboards.itely (right):
http://codereview.appspot.com/3782042/diff/1/Do
LGTM
I like this example of collisions better than the earlier one.
If there are no averse comments over Christmas I'll push this next week.
Thanks Keith.
http://codereview.appspot.com/3782042/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://codereview.appspot.com/3832046/diff/2001/input/regression/skyline-horizontal-padding.ly
File input/regression/skyline-horizontal-padding.ly (right):
http://codereview.appspot.com/3832046/diff/2001/input/regression/skyline-horizontal-padding.ly#newcode13
input/regression/skyline-horizontal
I've not tried following it, but it looks clear enough to me.
http://codereview.appspot.com/3823045/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
I made these changes in lilypond-book.py in the 2.15.40 binary
(different line numbers, but lines the same) and I can confirm they fix
the problem on Windows.
Thanks Julien!
Trevor
http://codereview.appspot.com/6342048/
___
lilypond-devel mail
Omitted to add -devel to Reviewers when I uploaded this patch.
Trevor
http://codereview.appspot.com/6347062/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2012/07/05 12:48:32, thomasmorley65 wrote:
Please add the newly implemented on-page-feature.
Done. I changed the description to fit better with
the column heading of the table.
http://codereview.appspot.com/6347062/
___
lilypond-devel mailing l
http://codereview.appspot.com/6347062/diff/1002/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):
http://codereview.appspot.com/6347062/diff/1002/Documentation/notation/input.itely#newcode1017
Documentation/notation/input.itely:1017: @item (on-page nmbr)
@ta
On 2012/07/06 07:38:05, dak wrote:
Yes, it's best to drop the verb. That is more consistent
with the rest of the table. But we are nitpicking here, aren't we :)
Done.
http://codereview.appspot.com/6347062/
___
lilypond-devel mailing list
lilypond-de
Reviewers: dak,
http://codereview.appspot.com/6354085/diff/1/Documentation/notation/spacing.itely
File Documentation/notation/spacing.itely (right):
http://codereview.appspot.com/6354085/diff/1/Documentation/notation/spacing.itely#newcode1182
Documentation/notation/spacing.itely:1182: to struct
http://codereview.appspot.com/6354085/diff/1/Documentation/notation/spacing.itely
File Documentation/notation/spacing.itely (right):
http://codereview.appspot.com/6354085/diff/1/Documentation/notation/spacing.itely#newcode1098
Documentation/notation/spacing.itely:1098: If this block:
On 2012/07/
I don't think all these functions should be in
ly/music-functions-init.ly, but I don't know the best place for them.
Someone more familiar with the layout of code may advise. The one
function that should be here is the one you asked about in your earlier
mail - crossStaff.
Trevor
http://codere
LGTM, apart from one minor change
http://codereview.appspot.com/6353081/diff/1/Documentation/notation/spacing.itely
File Documentation/notation/spacing.itely (right):
http://codereview.appspot.com/6353081/diff/1/Documentation/notation/spacing.itely#newcode906
Documentation/notation/spacing.itel
Patch pushed
91ca3dbe2cd40f8eedce48ee02c7c98a2ec89413
http://codereview.appspot.com/6347062/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Patch pushed
73255e50558a62841500aa947ff7cad28636d144
http://codereview.appspot.com/6354085/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Patch pushed
bcd9d85bfc1dd6cc2dd3e98901b4df33fd6d0989
http://codereview.appspot.com/6353079/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reviewers: ,
Message:
This is a substantial change. I took the opportunity to
deal with a TODO in the file - document \with - as
this made for a more sensible organisation of the section.
I'd like reviewers to consider in particular
- factual accuracy (I was not confident about some parts)
-
LGTM
Trevor
http://codereview.appspot.com/6345088/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Correct typo
http://codereview.appspot.com/6345086/diff/5001/Documentation/notation/changing-defaults.itely
File Documentation/notation/changing-defaults.itely (right):
http://codereview.appspot.com/6345086/diff/5001/Documentation/notation/changing-defaults.itely#newcode843
Documentation/notati
http://codereview.appspot.com/6345086/diff/5001/Documentation/notation/changing-defaults.itely
File Documentation/notation/changing-defaults.itely (right):
http://codereview.appspot.com/6345086/diff/5001/Documentation/notation/changing-defaults.itely#newcode844
Documentation/notation/changing-de
On 2012/07/12 10:20:01, dak wrote:
Uhm, wrong?
[etc]
Thanks David - that's the explanation I needed :)
I'll make amendments and post a new patch-set.
Trevor
http://codereview.appspot.com/6345086/
___
lilypond-devel mailing list
lilypond-devel@gn
On 2012/07/12 10:53:19, dak wrote:
I am not happy with all those fine distinctions and almost,
but not quite, similar syntax for property manipulations
in different contexts
I've done a lot of LP documentation in the past, and find it
is frequently the case that attempts to write down precise
Pushed to staging:
aebb391edacf9c1c0a2940d9c0ea9d632c12923e
and closed
http://codereview.appspot.com/6345086/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Just nitpicking; can't comment substantively.
Trevor
http://codereview.appspot.com/6432047/diff/1/lily/phrasing-slur-engraver.cc
File lily/phrasing-slur-engraver.cc (right):
http://codereview.appspot.com/6432047/diff/1/lily/phrasing-slur-engraver.cc#newcode256
lily/phrasing-slur-engraver.cc:2
LGTM
Trevor
http://codereview.appspot.com/6344092/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reviewers: eluzew_gmail.com,
Message:
I believe this doc change should be ok, but as I
am unable to easily do a full doc build it would
be helpful if a reviewer could offer to test this
for me and check the new example looks correct.
Trevor
Description:
Doc: clarify \header variables (2640)
Reviewers: ,
Message:
Pushed to staging as
3573a92d92728dc8d6452e5cd3cfba73e49e6990
Closing
Description:
Doc: correct warning re tied chords (2690)
Restore original wording which restricts this
warning to the control points of ties
Please review this at http://codereview.appspot.com/6427058/
On 2012/07/30 14:28:35, Graham Percival wrote:
... concerned that we discuss bookTitleMarkup and
scoreTitleMarkup.
These are discussed in Custom layout for title blocks
a little further down. But I see they are not indexed,
and a back reference there to this section is not well
worded. I'll
Just a query really, to help my understanding.
Trevor
http://codereview.appspot.com/6445056/diff/1/lily/lexer.ll
File lily/lexer.ll (right):
http://codereview.appspot.com/6445056/diff/1/lily/lexer.ll#newcode390
lily/lexer.ll:390: {RESTNAME}/[-_] |
Why is this trailing context added? I don't
Reviewers: ,
Message:
For Graham, really:
http://codereview.appspot.com/6452072/diff/1/Documentation/notation/rhythms.itely
File Documentation/notation/rhythms.itely (right):
http://codereview.appspot.com/6452072/diff/1/Documentation/notation/rhythms.itely#newcode2007
Documentation/notation/rh
Pushed to staging as
84f4009c40f44b13e933dfaeefe474cf9ac88a59
Closing
http://codereview.appspot.com/6456047/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
I can't test this, but eyeballing LGTM.
http://codereview.appspot.com/6445056/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
http://codereview.appspot.com/6445056/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
http://codereview.appspot.com/6449082/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
In vocal.itely both @subheading and @subsubheading are used.
The CG advice is to use @subheading.
Both have disadvantages:
@subheading looks like @unnumberedsubsubsec
@subsubheading looks like Known issues and warnings et al.
So maybe @i{@strong .. }} is not so bad after all, at least
in its
On 2012/08/03 09:35:47, dak wrote:
The obvious way would be to reorganize into fewer layers.
No. This is a long and complicated subsubsec and the point
of this issue is to improve clarity. The best way of doing
that is to introduce structure into the very long text. In
particular we need to
On 2012/08/04 08:27:10, dak wrote:
But again: the real issue to me seems that we are
hiding a long chapter inside of a subsubsec already.
I agree. But to fix that would require rewriting pretty
well the whole of chapter 1 of the NR. I'm not going to
do that. Let's just fix this simple issue
On 2012/08/04 09:33:33, dak wrote:
I don't see that ignoring even the proposal to use
a combination of structuring commands with explicit
markup is "the best course available".
I'm sorry - I completely missed this. Probably because
I was hung up by the earlier sneer and didn't take in
much el
OK, I think we've arrived at an acceptable solution,
albeit via a somewhat circuitous route, posted as patch
set 2.
I'll wait to see how this looks in the pdf version and
if all is well I'll add this recipe to the CG and change
the couple of other places where this level of structuring
is used.
1 - 100 of 556 matches
Mail list logo
