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
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
> 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
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
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
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/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
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 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
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
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
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.
-
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
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
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
>> 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
> 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
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
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/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 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
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
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
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
___
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
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
_
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
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 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
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,
30 matches
Mail list logo
