On 2013/02/11 20:53:53, Keith wrote:
On 2013/02/11 12:39:02, dak wrote:
> On 2013/02/11 09:25:20, dak wrote:
> > On 2013/02/11 06:18:57, Keith wrote:
> > >
> > > I was hoping to be able to provide a backward-compatibility
function, as
in
> > I did not even look at the proposed patch but it t
On 2013/02/11 12:39:02, dak wrote:
On 2013/02/11 09:25:20, dak wrote:
> On 2013/02/11 06:18:57, Keith wrote:
> >
> > I was hoping to be able to provide a backward-compatibility
function, as in
> I did not even look at the proposed patch but it touches several
binaries.
That
> should not be n
On 2013/02/11 09:25:20, dak wrote:
On 2013/02/11 06:18:57, Keith wrote:
> On 2013/02/09 08:54:03, dak wrote:
>
> > It doesn't matter. LilyPond is still being actively maintained.
If a
> > feature is required, it can be implemented properly, with a proper
> > interface, _without_ resorting to e
On 2013/02/11 06:18:57, Keith wrote:
On 2013/02/09 08:54:03, dak wrote:
> It doesn't matter. LilyPond is still being actively maintained. If
a
> feature is required, it can be implemented properly, with a proper
> interface, _without_ resorting to exploits.
>
I was hoping to be able to
On 2013/02/09 08:54:03, dak wrote:
It doesn't matter. LilyPond is still being actively maintained. If a
feature is required, it can be implemented properly, with a proper
interface, _without_ resorting to exploits.
I was hoping to be able to provide a backward-compatibility function, as
in
ource that would be change to the worse with patch
> applied?
Nope. I still encourage caution, because people use LilyPond for
very academic projects. Also, it is academically possible that some
programmer will want to add a override-able property that is a pitch
that should be transposed
On Fri, 08 Feb 2013 01:20:59 -0800, wrote:
On 2013/02/08 08:40:29, dak wrote:
On 2013/02/08 04:46:27, Keith wrote:
> Yesterday's patch was better.
I beg to differ. It did not address instrument definitions, or manual
settings
Well, we had a nice plane for \instrumentSwitch,
and I did no
On 2013/02/08 08:40:29, dak wrote:
On 2013/02/08 04:46:27, Keith wrote:
> Yesterday's patch was better.
I beg to differ. It did not address instrument definitions, or manual
settings
Concretely: can you show an example of not-just-academical LilyPond
source that would be change to the worse
379: (untransposable . #t)
Well, not every Grob property that is a pitch is untransposable. The
second
pitch in a pitchedTrill, for example, should be transposed along with
the first
pitch.
I don't see that there is any interface for pitched Trills that would
ride on explicit property set
Yesterday's patch was better.
The 'untransposable property is more closely related to the source of
the events (\transposition or \instrumentSwitch) than to the event type
(override or propertySet).
https://codereview.appspot.com/7303057/diff/2001/scm/define-music-types.scm
File scm/define-music
On 16 June 2011 17:28, wrote:
> I won't bother with an issue tracker item for this; I think it's
> simple+clear enough that it can be pushed without a full "patch
> countdown".
Thanks, pushed: eb307731804e61efcb62a13ebbf13da5bb050f3f
Cheers,
Neil
__
LGTM.
I won't bother with an issue tracker item for this; I think it's
simple+clear enough that it can be pushed without a full "patch
countdown".
http://codereview.appspot.com/4571080/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://li
LGTM
http://codereview.appspot.com/4571080/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
c1
}
\addlyrics {
\set stanza = \markup \box "1"
foo
}
-> error: syntax error, unexpected LYRIC_MARKUP
Description:
Property setting in lyrics: allow markup
* input/regression/stanza-number.ly:
test markup as well as bare string
* lily/parser.yy (scalar):
use lyric_elem
[EMAIL PROTECTED] writes:
> Well. Will it be okay that I add the aliasses to the contexts?
> No syntax changes, just some \aliasses in engraver-init.ly
no prob.
> > I think that the current behavior is just as bad as your suggestion. I
> > would prefer that the kind of advanced behavior you wan
Han-Wen wrote:
> first of all, I don't see the point, in this sense: the number of
> people that will deviate from the default accidentals is so small that
> it doesn't warrant drastic additions to the syntax/semantics. (perhaps
> I said this earlier, and you replied, but I forgot your motivation
[EMAIL PROTECTED] writes:
> It should be possible without any hacking to set properties in different
> contexts using the same macro.
>
> The burning reason for this is the accidental macros - but also other
> macros might come in handy. I.e. being able to say \clef F in start of
> the score t
It should be possible without any hacking to set properties in different
contexts using the same macro.
The burning reason for this is the accidental macros - but also other
macros might come in handy. I.e. being able to say \clef F in start of
the score to get F-clefs in all staves would be q
18 matches
Mail list logo
