Looks fine, but I thought you wanted to use only one of
outside-staff-horizontal-padding
or
skyline-horizontal-padding
I need to be clear on this because I'm implementing \markLengthOn and
the analogous \textLengthOn needed to remove these paddings.
https://codereview.appspot.com/8632044/di
LGTM (including your local correction).
Add some new index entries for concepts discussed in this section
(please feel free to correct my suggestions if they fall foul of the
doc. standards).
Cheers, Ian
https://codereview.appspot.com/8853044/diff/3001/Documentation/extending/programming-interf
Ready for testing and review now.
https://codereview.appspot.com/8853044/diff/3001/Documentation/extending/programming-interface.itely
File Documentation/extending/programming-interface.itely (right):
https://codereview.appspot.com/8853044/diff/3001/Documentation/extending/programming-interface
On 2013/04/17 18:27:05, MikeSol wrote:
Hey, I hadn't seen this. I just finished writing an equivalent patch.
Yours is
better, so keep it. You can use this for the
inherit-X-parent-visibility and
eliminate the inherit-Y-parent-visibility callback, which is cruft and
can be
replaced with the
[Only to lily-devel since it doesn't directly affect the bug.]
> As to "how much work do you estimate writing PDFs ourselves" to be:
> perfect scope for a GSoC project as it mostly involves
> straightforward coding with both the PostScript and PDF reference in
> hand.
Well, *now* is the time to
Hi James
I just wanted to tell you how invaluable these summaries are when one has
several patches in the pipe-lines! I don't think I could keep track of them
all without it. Thank you!
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
h
Reviewers: ,
Message:
I'll add the change to EM 2.1 as part of Patch Set 2 shortly
Description:
Doc: Change \on-the-fly #procedure to \on-the-fly \procedure (3098)
This avoids problems when \on-the-fly is used within #{ .. #}
Please review this at https://codereview.appspot.com/8853044/
Aff
ArnoldTheresius wrote
>
> Eluze wrote
>> ...
>> if this is possible we could abandon the entry LYEDITOR?! (at least for
>> windows)
> Well,
> I would keep the environment variable(s) as a last, top priotiry choice to
> select which editor one is using.
why not - I just mean don't use it if you do
On 18 avr. 2013, at 10:51, k-ohara5...@oco.net wrote:
> I suggest that you set the defaults consistently for all text grobs, so
> that I don't have to file bug reports one-at-a-time for every possible
> case:
>
> \paper { indent = 0\mm
> line-width = 42.2\mm
> ragged-right = ##f }
> \score { << \
Eluze wrote
> ...
> if this is possible we could abandon the entry LYEDITOR?! (at least for
> windows)
>
> Eluze
Well,
I would keep the environment variable(s) as a last, top priotiry choice to
select which editor one is using.
From scm/editor.scm:
/(define (get-editor)
(or (getenv "LYEDITOR")
LGTM. Great work!
https://codereview.appspot.com/8189043/diff/45001/Documentation/learning/tweaks.itely
File Documentation/learning/tweaks.itely (right):
https://codereview.appspot.com/8189043/diff/45001/Documentation/learning/tweaks.itely#newcode2288
Documentation/learning/tweaks.itely:2288:
I suggest that you set the defaults consistently for all text grobs, so
that I don't have to file bug reports one-at-a-time for every possible
case:
\paper { indent = 0\mm
line-width = 42.2\mm
ragged-right = ##f }
\score { << \new Staff { b1_\markup\huge"innocent" }
\new Staff << { e''4 e''
12 matches
Mail list logo