Mark Polesky wrote Saturday, July 25, 2009 4:29 AM
We all okay with this patch?
LGTM
Of course it's a new command and a syntax change; I don't know if
that means some special process has to be taken; updating the
parser, etc. I have no idea, actually. Let me know.
Nothing else is needed,
On Fri, Jul 24, 2009 at 10:30:30PM -0700, Graham Percival wrote:
> On Fri, Jul 24, 2009 at 06:15:31PM -0700, Mark Polesky wrote:
> > Thanks, Neil. My editor does confusing things with tabs.
> > I hate them. Who would object if I just started running
> > tabs->spaces on the source docs? I think we s
Graham Percival wrote:
> On Fri, Jul 24, 2009 at 06:15:31PM -0700, Mark Polesky wrote:
> > Thanks, Neil. My editor does confusing things with tabs.
> > I hate them. Who would object if I just started running
> > tabs->spaces on the source docs? I think we should have
> > a strict no-tabs rule. An
On Fri, Jul 24, 2009 at 06:15:31PM -0700, Mark Polesky wrote:
> Thanks, Neil. My editor does confusing things with tabs.
> I hate them. Who would object if I just started running
> tabs->spaces on the source docs? I think we should have
> a strict no-tabs rule. And I'm in good company:
> http://lis
> I've uploaded the patch for review at
> http://codereview.appspot.com/97119
Since I don't understand the code at all, I've only a minor comment:
Please use two spaces after a full stop in documentation strings for
consistence.
Thanks for your hard work!
Werner
_
We all okay with this patch?
Of course it's a new command and a syntax change; I don't know if
that means some special process has to be taken; updating the
parser, etc. I have no idea, actually. Let me know.
Thanks.
- Mark
0001-Add-dynamic-script-f-update-docs.patch
Description: B
I've uploaded the patch for review at
http://codereview.appspot.com/97119
It's pretty huge, but many of the changes are just due to changes in the
properties that control vertical spacing. Also, annotate-spacing is
broken, but the fixes for that should be confined to scm/page.scm.
Joe
___
Neil Puttock wrote:
> Not quite:
> indentation
> whitespace/indentation
> missing ref-ify
> indentation
Thanks, Neil. My editor does confusing things with tabs.
I hate them. Who would object if I just started running
tabs->spaces on the source docs? I think we should have
a strict no-tabs rule. A
Reviewers: joeneeman,
http://codereview.appspot.com/96083/diff/1/8
File lily/pango-font.cc (right):
http://codereview.appspot.com/96083/diff/1/8#newcode351
Line 351: // options.
On 2009/07/21 18:43:10, joeneeman wrote:
Could you please have a look at this? (after applying this patch, if
you
2009/7/24 Carl Sorensen :
>> type check also for settings?
>
> Settings needs a list? type check, and I haven't seen one available
> in c++. It shouldn't segfault, because we do a pair check before we
> use it.
ly_is_list (which is a wrapper for scm_list_p) (but see below)
>
> I can't use a pai
2009/7/23 Valentin Villenave :
> do you want me to open a "Started" page in the tracker to keep track
> of this patch?
Cheers for the offer, but I don't think it's necessary. Once I've
dealt with Carl's comments on the latest patch, I think it'll be ready
for pushing. Then we can decide what's
2009/7/24 Mark Polesky :
> Okay to apply?
Not quite:
+ (map ref-ify
indentation
+ (sort
whitespace/indentation
+ (map symbol->string
+ (hashq-ref iface->grob-table
+
2009/7/24 Graham Percival :
> Bad idea, since we eventually *will* be releasing another 2.12,
> and it wouldn't be a bad idea to update lsr in it. It's not worth
> changing them back now, but as a general rule, don't do this.
I'm not too bothered if this happens, since deleted snippets stick out
> I reformatted the output (slightly) to minimize duplicates. Do you
> prefer this version or the earlier one?
The more compact solution is the better one. A minor nit: Please
start the output with a newline: I get this on the TTY:
Interpretation der Musik...
Vorverarbeitung der grafischen
>> Thanks for adding this to the snippets. Maybe I'll post a better
>> explanation later. Anyway, wouldn't it be better to add this to the
>> font?
>
> For a single vertical line, I suspect this would be overkill –
> Unless we officialy include it alongside the other articulation
> marks. Werner
Okay to apply?
- Mark
0001-IR-3-Backend-More-auto-sorting.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Le jeudi 23 juillet 2009 à 14:11 -0700, Mark Polesky a écrit :
> I assume that a comprehensive visual "parent-web" demonstrating
> all such relationships would be too convoluted to have any
> practical value, and too difficult to generate to even justify
> trying such a thing
It might be doable to
On 7/22/09 4:15 PM, "joenee...@gmail.com" wrote:
> I think this is pretty much ready to commit
>
>
> http://codereview.appspot.com/88155/diff/3101/4032
> File lily/beam-scheme.cc (right):
>
> http://codereview.appspot.com/88155/diff/3101/4032#newcode2
> Line 2: beam-scheme.cc -- Retrieving
On Thu, Jul 23, 2009 at 9:11 PM, Mark Polesky wrote:
>
> Does a grob-type always have the same set of parent-types?
>
Not necessarily; It often depends on how the context that the grob
originates from is nested into the rest of the contexts. Check the
source code for Grob::set_parent() calls.
-
Mark Polesky wrote Friday, July 24, 2009 3:16 AM
One wrinkle is that compiling and testing things with "make doc"
is (at the moment) out of the question on the computer that I
currently have access to. Which means that I can't definitively
prove that my patches don't break anything, even though
2009/7/24 Mark Polesky :
> In a weird way, I don't think either is appropriate. Sometimes I wish
> there was something like an LSRD (for developers). You know, snippets
> showing how to trace grob-parents, how to sort objects by specific
> properties, how to know when to use #'(0 . 1) and when to u
2009/7/24 Maximilian Albert :
> It's not correct that articulations are always centered with the note head.
> See
>
> http://code.google.com/p/lilypond/issues/detail?id=218
>
> and the examples attached there. This is precisely what
> toward-stem-shift was introduced for. :-)
Indeed (i didn't re
Valentin Villenave wrote:
> What do you guys would like to do with it? LSR? Docs? Anywhere else?
In a weird way, I don't think either is appropriate. Sometimes I wish
there was something like an LSRD (for developers). You know, snippets
showing how to trace grob-parents, how to sort objects by sp
2009/7/24 Valentin Villenave :
>> Another point is the horizontal position: If the line is placed above the
>> stem, it seems better to me to have both in one horizontal position (not
>> centered above the NoteHead), though I can't recognize any clear conventions
>> for it up to now.
>
> I think t
2009/7/24 Werner LEMBERG :
> Definitely very useful stuff!
... and it would be a shame to lose track of it :-)
What do you guys would like to do with it? LSR? Docs? Anywhere else?
Regards,
Valentin
___
lilypond-devel mailing list
lilypond-devel@gnu.o
2009/7/23 Michael Käppler :
> Thanks for adding this to the snippets. Maybe I'll post a better explanation
> later. Anyway, wouldn't it be better to add this to the font?
For a single vertical line, I suspect this would be overkill – Unless
we officialy include it alongside the other articulation
Werner LEMBERG wrote:
> Very nice! Perhaps this can be wrapped into an even more convenient
> function so that a user just have to say, for example,
>
> \getAncestry { }
>
> at the place where grobs have to be manipulated.
>
> Definitely very useful stuff!
Werner,
I reformatted the output
> Here's one way of doing it (from within a music block).
Very nice! Perhaps this can be wrapped into an even more convenient
function so that a user just have to say, for example,
\getAncestry { }
at the place where grobs have to be manipulated.
Definitely very useful stuff!
Werner
Hi Valentin,
Greetings,
here is how to achieve what you're looking for (it has been added to
the documentation snippets as well, since this notation is indeed
common):
http://lsr.dsi.unimi.it/LSR/Item?id=620
Thanks for adding this to the snippets. Maybe I'll post a better
explanation later. A
On Fri, Jul 24, 2009 at 08:36:50AM +0200, Valentin Villenave wrote:
> 2009/7/24 Graham Percival :
> > On Thu, Jul 23, 2009 at 08:55:21PM -0600, Carl Sorensen wrote:
> >> Please remove the docs tags from the following snippets:
> >>
> >> Specifying context with beatGrouping
> >>
> >> Using beatL
30 matches
Mail list logo
