LGTM.
https://codereview.appspot.com/9295044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On Sat, 22 Jun 2013 02:35:33 -0700, wrote:
Anyway, just picked this patch again and it failed make doc, so I did it
again and it still failed make doc. I've not yet dug through the logs,
but could this be anything to do with the last two checkins?
I do not see anything in the last few commits
I saw that there were some translation merges and David put in his elisp
fix as well, but I think I already ran my tests against that yesterday.
Anyway, to save time for pathcy, when ever I see a merge has taken place
I test a random patch (regardless if it fails) so that Patchy has a new
baselin
On 2013/06/14 02:32:29, Keith wrote:
I'll have time to try make doc and re-upload, this weekend.
I could not yet get `make doc` to complete, probably due to some problem
in my build-directory setup.
https://codereview.appspot.com/9295044/
___
lilypo
I'll have time to try make doc and re-upload, this weekend.
https://codereview.appspot.com/9295044/diff/51001/lily/stencil-integral.cc
File lily/stencil-integral.cc (right):
https://codereview.appspot.com/9295044/diff/51001/lily/stencil-integral.cc#newcode385
lily/stencil-integral.cc:385: Inter
On 2013/06/13 16:40:46, dak wrote:
https://codereview.appspot.com/9295044/diff/51001/scm/define-markup-commands.scm
File scm/define-markup-commands.scm (right):
https://codereview.appspot.com/9295044/diff/51001/scm/define-markup-commands.scm#newcode1913
scm/define-markup-commands.scm:1913: #
https://codereview.appspot.com/9295044/diff/51001/scm/define-markup-commands.scm
File scm/define-markup-commands.scm (right):
https://codereview.appspot.com/9295044/diff/51001/scm/define-markup-commands.scm#newcode1913
scm/define-markup-commands.scm:1913: #:properties (pad-around-markup)
Remove
On Thu, 13 Jun 2013 02:13:55 -0700, wrote:
https://codereview.appspot.com/9295044/diff/51001/scm/harp-pedals.scm#newcode128
scm/harp-pedals.scm:128: (apply ly:stencil-add
Uh, (apply x (cons* y z t)) is just the same as
(apply x y z t)
isn't it?
Don't ask me; I learned Scheme five minutes bef
https://codereview.appspot.com/9295044/diff/51001/lily/stencil-integral.cc
File lily/stencil-integral.cc (right):
https://codereview.appspot.com/9295044/diff/51001/lily/stencil-integral.cc#newcode385
lily/stencil-integral.cc:385: Interval x_ext = robust_scm2interval
(scm_car (expr), Interval ()
https://codereview.appspot.com/9295044/diff/51001/scm/harp-pedals.scm
File scm/harp-pedals.scm (right):
https://codereview.appspot.com/9295044/diff/51001/scm/harp-pedals.scm#newcode128
scm/harp-pedals.scm:128: (apply ly:stencil-add
Uh, (apply x (cons* y z t)) is just the same as
(apply x y z t)
"Keith OHara" writes:
> On Thu, 13 Jun 2013 01:02:34 -0700, wrote:
>
>> On 2013/06/13 07:45:09, Keith wrote:
>>
>>> It could be 'dimension-stencil as it lives alongside 'rotate-stencil,
>>> 'scale-stencil, etc.,
>>
>> Well, "rotate" and "scale" are verbs and "dimension" isn't, so that
>> particu
On Thu, 13 Jun 2013 01:02:34 -0700, wrote:
On 2013/06/13 07:45:09, Keith wrote:
It could be 'dimension-stencil as it lives alongside 'rotate-stencil,
'scale-stencil, etc.,
Well, "rotate" and "scale" are verbs and "dimension" isn't, so that
particular form has me less than enthused. I am al
On 2013/06/13 07:45:09, Keith wrote:
On 2013/06/12 19:02:55, dak wrote:
>
https://codereview.appspot.com/9295044/diff/37001/scm/define-markup-commands.scm
> File scm/define-markup-commands.scm (right):
>
>
https://codereview.appspot.com/9295044/diff/37001/scm/define-markup-commands.scm#newco
On 2013/06/12 19:02:55, dak wrote:
https://codereview.appspot.com/9295044/diff/37001/scm/define-markup-commands.scm
File scm/define-markup-commands.scm (right):
https://codereview.appspot.com/9295044/diff/37001/scm/define-markup-commands.scm#newcode1911
scm/define-markup-commands.scm:1911: (
https://codereview.appspot.com/9295044/diff/37001/scm/define-markup-commands.scm
File scm/define-markup-commands.scm (right):
https://codereview.appspot.com/9295044/diff/37001/scm/define-markup-commands.scm#newcode1911
scm/define-markup-commands.scm:1911: (list 'explicit-extent-stencil x y
(ly:s
d...@gnu.org wrote Wednesday, June 12, 2013 6:42 AM
> I disagree. There is harm in having both since it makes people think
> about which to use in which situation. Since we have \pad-x and \pad-y,
> \pad-around makes more sense to keep. Not only does the name help with
> knowing just what is p
On 2013/06/11 16:15:45, Keith wrote:
> I see that they are completely identical, even after your patch!
This should
> probably be fixed too, both in the docs and in the code...
There is no harm in having both. There might be people who habitually
use
each, and we cannot convert-ly their
But \pad-around #-1 does work to reduce the extent of markup,
and there is no reason to disallow that.
OK. However, we need good documentation examples...
> In particular, I can't see any difference
> between \pad-around and \pad-markup.
There is no harm in having both.
Of course not, but
On 2013/06/11 06:40:13, lemzwerg wrote:
Yes, the union, since the documentation of \pad-to box says `at least
the X-EXT,
Y-EXT space'. However, the documentation strings for all \pad-XXX
functions
should be updated accordingly.
But \pad-around #-1 does work to reduce the extent of markup,
One possibly-interesting choice is whether the stencil-padding
functions should
always replace the skyline with a box, or make the union of the
skyline with the
box. Clearly \with-dimensions needs to replace the skyline with a box
for your
kludge \with-dimensions #'(0 . 0) #'(0 . 0) . Howe
20 matches
Mail list logo
