On the other hand, things like \overrideProperty can only have one
interface or the other, and put a single dotted symbol list here to
specify the path with no alternative readings is dead simple and
straightforward. And starting with version 2.19, or at the latest
2.21, I would want to
Werner LEMBERG wl at gnu.org writes:
Instead of having an optional argument
Remember that David's previous approach used no optional arguments,
the optional components were attached with dots to the core arguments
\override [Context.]Grob property[.subproperty] = #value
\tweak
Keith OHara k-ohara5...@oco.net writes:
Werner LEMBERG wl at gnu.org writes:
Instead of having an optional argument
Remember that David's previous approach used no optional arguments,
the optional components were attached with dots to the core arguments
\override [Context.]Grob
Keith OHara k-ohara5...@oco.net writes:
Werner LEMBERG wl at gnu.org writes:
Instead of having an optional argument
Remember that David's previous approach used no optional arguments,
the optional components were attached with dots to the core arguments
\override [Context.]Grob
David Kastrup d...@gnu.org writes:
Werner LEMBERG w...@gnu.org writes:
On the other hand: Wouldn't it be possible to make LilyPond simply
walk over all possible combinations to find out whether, say,
foo.bar
is a context followed by a property, or a property followed by a
sub-property,
On 2012-10-13 07:30, Keith OHara wrote:
Can anyone reading here (other than David who implemented it) give an
example where he has used the grob-augmented \tweak syntax ?
I had to use it to change the parentheses of \parenthesize, e.g. to use
square brackets or to use only a left or right
On the other hand: Wouldn't it be possible to make LilyPond simply
walk over all possible combinations to find out whether, say,
foo.bar
is a context followed by a property, or a property followed by a
sub-property, etc.?
Technically impossible. At the time an \override is parsed, the
Werner LEMBERG w...@gnu.org writes:
On the other hand: Wouldn't it be possible to make LilyPond simply
walk over all possible combinations to find out whether, say,
foo.bar
is a context followed by a property, or a property followed by a
sub-property, etc.?
Technically impossible. At
On 2012-10-12 00:25, David Kastrup wrote: \tweak gets one symbol list,
\override gets two symbol lists. The
symbol list for \tweak may optionally start with a grob name, the first
symbol list for \override may optionally start with a context name. I
can offer \tweak color.Accidental #red
David,
On Fri, Oct 12, 2012 at 7:57 AM, David Kastrup d...@gnu.org wrote:
AFAIK, compilers do something similar, warning about ambiguities.
It is one of the sad facets of communication that the mood-deteriorating
effects of unintentional satire are quite similar to that of the real
deal.
I
Janek Warchoł janek.lilyp...@gmail.com writes:
On Fri, Oct 12, 2012 at 7:57 AM, David Kastrup d...@gnu.org wrote:
AFAIK, compilers do something similar, warning about ambiguities.
It is one of the sad facets of communication that the mood-deteriorating
effects of unintentional satire are
2012/10/9 David Kastrup d...@gnu.org:
Since this patch series is a bit humongous for reviewing in a single
Rietveld review and it would take two months to get every patch in
sequence through an individual review, I am putting this series out as
an experiment to the list.
Let's see how we
Hi,
i'm short on time so i'll try to be brief - hopefully this won't cause
any misunderstanding.
David, i understand that some comments and questions may look like the
sender is questioning your knowledge in some area.
I want to assure you that when i ask such a stupid question, i'm not
However, one could change the current
\tweak Accidental.color into
\grob Accidental \tweak color ...
and similarly for other tweaks: \grob name would just take the next
music element, take a look at the last applied tweak and make it
specific to one grob type. Better names welcome. It
Hello,
On 10 Oct 2012, at 21:02, Werner LEMBERG w...@gnu.org wrote:
X-offset anyone?
... should be renamed IMHO. Regardless of our discussion, it
doesn't fit into the current naming scheme.
The corresponding axis is called X, and using x for a constant in
the expectation that the user
James pkx1...@gmail.com writes:
On 10 Oct 2012, at 21:02, Werner LEMBERG w...@gnu.org wrote:
X-offset anyone?
... should be renamed IMHO. Regardless of our discussion, it
doesn't fit into the current naming scheme.
The corresponding axis is called X, and using x for a constant in
the
[...] I still don't want to make the interpretation of identifiers
depend on case other than, of course, that you need to stick with
the exact spelling of an identifier once you picked its name.
Besides limiting the namespace of user variables, what are your
arguments against such a change?
Werner LEMBERG w...@gnu.org writes:
[...] I still don't want to make the interpretation of identifiers
depend on case other than, of course, that you need to stick with
the exact spelling of an identifier once you picked its name.
Besides limiting the namespace of user variables, what are
\tweak Accidental.color #red cis
vs.
\override Voice.Accidental color #red
\tweak gets one symbol list, \override gets two symbol lists. The
symbol list for \tweak may optionally start with a grob name, the
first symbol list for \override may optionally start with a context
name.
Werner LEMBERG w...@gnu.org writes:
On the other hand: Wouldn't it be possible to make LilyPond simply
walk over all possible combinations to find out whether, say,
foo.bar
is a context followed by a property, or a property followed by a
sub-property, etc.? Is this too expensive? Or is
Colin Campbell c...@shaw.ca writes:
On 12-10-09 12:59 PM, David Kastrup wrote:
Since this patch series is a bit humongous for reviewing in a single
Rietveld review and it would take two months to get every patch in
sequence through an individual review, I am putting this series out as
an
Ok, here are a few followup thoughts. One: response to the on-list
posting of the patches, intended to be more useful for per-patch review,
has resulted in zero followups.
I'll put out the next iteration to the lilypond-auto list for that
reason, at least I'll attempt doing so (the list page
One: response to the on-list posting of the patches, intended to be
more useful for per-patch review, has resulted in zero followups.
Well I've already checked your changes on Rietveld, so I simply
skipped the patches sent to lilypond-devel.
\tweak has an optional grob argument (now a
Werner LEMBERG w...@gnu.org writes:
One: response to the on-list posting of the patches, intended to be
more useful for per-patch review, has resulted in zero followups.
Well I've already checked your changes on Rietveld, so I simply
skipped the patches sent to lilypond-devel.
\tweak has
Would it be possible to have
\override Accidental.color #red
\override Voice.Accidental.color
? For me, this feels most natural.
Won't work since you can't distinguish
\override Voice.Accidental.color
from
\override Accidental.bound-details.left
and I really don't want to
Werner LEMBERG w...@gnu.org writes:
Would it be possible to have
\override Accidental.color #red
\override Voice.Accidental.color
? For me, this feels most natural.
Won't work since you can't distinguish
\override Voice.Accidental.color
from
\override
Would it be possible to have
\override Accidental.color #red
\override Voice.Accidental.color
? For me, this feels most natural.
Won't work since you can't distinguish
\override Voice.Accidental.color
from
\override Accidental.bound-details.left
and I really don't want to try
Werner LEMBERG w...@gnu.org writes:
Would it be possible to have
\override Accidental.color #red
\override Voice.Accidental.color
? For me, this feels most natural.
Won't work since you can't distinguish
\override Voice.Accidental.color
from
\override
[...] I really don't want to try picking this apart based on
uppercase/lowercase letter distinctions.
After some thinking I wonder why not?
X-offset anyone?
... should be renamed IMHO. Regardless of our discussion, it doesn't
fit into the current naming scheme.
Werner
Werner LEMBERG w...@gnu.org writes:
[...] I really don't want to try picking this apart based on
uppercase/lowercase letter distinctions.
After some thinking I wonder why not?
X-offset anyone?
... should be renamed IMHO. Regardless of our discussion, it doesn't
fit into the current
David Kastrup d...@gnu.org writes:
Werner LEMBERG w...@gnu.org writes:
[...] I really don't want to try picking this apart based on
uppercase/lowercase letter distinctions.
After some thinking I wonder why not?
X-offset anyone?
... should be renamed IMHO. Regardless of our discussion,
X-offset anyone?
... should be renamed IMHO. Regardless of our discussion, it
doesn't fit into the current naming scheme.
The corresponding axis is called X, and using x for a constant in
the expectation that the user would not attempt naming a variable
after it would seem rather
Since this patch series is a bit humongous for reviewing in a single
Rietveld review and it would take two months to get every patch in
sequence through an individual review, I am putting this series out as
an experiment to the list.
Let's see how we fare.
On 12-10-09 12:59 PM, David Kastrup wrote:
Since this patch series is a bit humongous for reviewing in a single
Rietveld review and it would take two months to get every patch in
sequence through an individual review, I am putting this series out as
an experiment to the list.
Let's see how we
34 matches
Mail list logo
