Many of my general comments were in my reply to your message. There are
some specifics in the files here.
Thanks,
Carl
http://codereview.appspot.com/3031041/diff/30001/lily/axis-group-interface.cc
File lily/axis-group-interface.cc (right):
http://codereview.appspot.com/3031041/diff/30001/li
On 2010/11/11 03:53:44, Mark Polesky wrote:
Here's a new patch-set for renaming the vertical spacing
grob properties. But...
I'm kind of going in circles trying to decide where to put
some things:
1) individual alist-key descriptions
2) individual grob-property descriptions
3) non-staff li
Reviewers: ,
Message:
Here's a new patch-set for renaming the vertical spacing
grob properties. But...
I'm kind of going in circles trying to decide where to put
some things:
1) individual alist-key descriptions
2) individual grob-property descriptions
3) non-staff line reference-points
I wan
On 11/10/10 9:05 PM, "Mark Polesky" wrote:
> The \paper variables are completely absent from the IR.
> Shouldn't they be included in an "internals reference"?
>
I assume so. Let's open a tracker issue
Carl
___
lilypond-devel mailing list
lilyp
The \paper variables are completely absent from the IR.
Shouldn't they be included in an "internals reference"?
- Mark
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
On Mon, Nov 08, 2010 at 01:26:41PM +0100, Xavier Scheuer wrote:
> On 8 November 2010 13:05, Valentin Villenave wrote:
> > Please repost your mail as a comment there, I think it will be more
> > appropriate, useful and (possibly) efficient :-)
>
> Actually I'm sad when I see this issue is tagged "
It's now been a week since report 22 came out and the -hackers
drama began.
The positive outcome is:
- we pushed an 18-line patch to the CG which says "there is a
dormant lilypond-hackers mailing list, which we'll sort out
after 2.14 is out".
The neutral outcome is our policies -- there was n
On Sun, Nov 07, 2010 at 01:33:48PM -0800, Keith E OHara wrote:
> In fact, those tests did not include a case of Lyrics above their affinity
> staff. My change (2b) placed a minimum-space rod from the centerline of the
> staff to the baseline of Lyrics, which pushes lyrics-above too far away.
>
> Hope that helps... I'm attempting a GUB build for binary distribution
> and fighting another problem :-)
I've created a GUB installer for linux-x86
http://lilypond.org/schikkers-list/download/
Example usage
schikkers-list or
schikkers-list ~/schikkers-list/usr/share/ikli/input/t
Hi Patrick,
On 10/11/10 06:01, pnor...@gmail.com wrote:
> 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
Trevor Daniels wrote Tuesday, October 19, 2010 8:34 PM
Keith E OHara wrote Monday, October 18, 2010 11:40 PM
I suggest (diff attached) removing the part about
instrumentCueName in favor of a fuller example for \killCues.
The manual teaches markup elsewhere; the challenge with cue-note
label
On Tue, Nov 9, 2010 at 5:40 PM, Werner LEMBERG wrote:
> My question: Is it possible to implement a warning message for the
> former case
I'm not sure how that would work. Perhaps we could add a check_context
function to property-iterator.cc, in addition to the existing
check_grob function?
Anywa
>> What do you think about activating this by default in lilypond-book
>> (and possibly providing an option to disable this)?
>
> If this is a question about our build process (as I believe), then
> whether or not it's enabled by default in lilypond-book is
> completely separate issue.
It's both
>> Especially the `sM2semimensural' in `parmesan20' (which I'm
>> currently looking at after applying the patch locally) looks very
>> strange, and I've never seen a similar note shape before. But I
>> suspect this is my lack of knowledge.
>
> I'll try to compile a list of online facsimiles.
Ye
hi all,
> Regarding the quality of the patch: It's just fine. However, I can't
> say anything about the details since my knowledge of mensural notation
> is very limited. Especially the `sM2semimensural' in `parmesan20'
> (which I'm currently looking at after applying the patch locally)
> looks
15 matches
Mail list logo
