On 2014/10/09 08:11:29, uliska wrote:
On 2014/10/08 05:01:40, Keith wrote:
> Why not store the common music in a variable, and show
> \score {\music}
> \discaredOriginalBreaks
> \score {\music}
> ?
Because it wouldn't work that way. \discardOriginalBreaks
would be interpreted when the comma
2014-10-09 11:38 GMT+02:00 Urs Liska :
> Because one wouldn't want to *finally* produce a version of the score with
> the breaks of the original score. If that's my interest (which then would
> actually be a "rather specific situation") I can simply use hardcoded
> \break commands.
>
> The whole p
2014-10-09 12:41 GMT+02:00 Graham Percival :
> On Thu, Oct 09, 2014 at 10:21:45AM +, tdanielsmu...@googlemail.com
> wrote:
> > I've not followed the corresponding email discussion closely, and maybe
> > I've missed something, but how is this better than simply using \obreak
> > for an original
Greetings,
having pushed the recent "string-number-styles" patch, I thought another
area where we might benefit from roman numerals would be page numbers.
This is an attempt at getting there.
https://codereview.appspot.com/151230044/
___
lilypond-dev
On Thu, 2014-10-09 at 11:36 +, d...@gnu.org wrote:
> On 2014/10/09 11:08:16, richard_rshann.plus.com wrote:
> > On Wed, 2014-10-08 at 17:41 +, mailto:d...@gnu.org wrote:
> > > Reviewers: ,
> > >
> > >
> > >
> https://codereview.appspot.com/153160043/diff/1/scm/chord-ignatzek-names.scm
> > >
On 2014/10/09 11:08:16, richard_rshann.plus.com wrote:
On Wed, 2014-10-08 at 17:41 +, mailto:d...@gnu.org wrote:
> Reviewers: ,
>
>
>
https://codereview.appspot.com/153160043/diff/1/scm/chord-ignatzek-names.scm
> File scm/chord-ignatzek-names.scm (right):
>
>
https://codereview.appspot.co
Hello,
Here is the current patch countdown list. The next countdown will be on
October 12th.
You can always view the most current countdown list here:
http://code.google.com/p/lilypond/issues/list?q=Patch%3Apush%2Ccountdown%2Creview%2Cnew%2Cwaiting&colspec=Patch%20Owner%20ID%20Summary&sort=pat
On Wed, 2014-10-08 at 17:41 +, d...@gnu.org wrote:
> Reviewers: ,
>
>
> https://codereview.appspot.com/153160043/diff/1/scm/chord-ignatzek-names.scm
> File scm/chord-ignatzek-names.scm (right):
>
> https://codereview.appspot.com/153160043/diff/1/scm/chord-ignatzek-names.scm#newcode98
> scm/c
On 2014/10/09 10:21:45, Trevor Daniels wrote:
It would also be trivial to remove all these editing aids finally with
a simple
global edits.
I think the basic point was to get different aspects of the same
document _without_ doing any edits on it.
https://codereview.appspot.com/150670043/
_
On Thu, Oct 09, 2014 at 10:21:45AM +, tdanielsmu...@googlemail.com wrote:
> I've not followed the corresponding email discussion closely, and maybe
> I've missed something, but how is this better than simply using \obreak
> for an original break, and \nbreak for a new, required, break, having
>
I've not followed the corresponding email discussion closely, and maybe
I've missed something, but how is this better than simply using \obreak
for an original break, and \nbreak for a new, required, break, having
defined
obreak = \break
nbreak = <>
in order to obtain the original breaks. And t
Am 09.10.2014 11:48, schrieb Phil Holmes:
- Original Message - From: "Urs Liska"
Your extension makes only very limited sense for scores reproducing the
"original breaks" of a single canonical original document. That's a
rather specific situation.
Now I start to see your misundersta
- Original Message -
From: "Urs Liska"
Your extension makes only very limited sense for scores reproducing the
"original breaks" of a single canonical original document. That's a
rather specific situation.
Now I start to see your misunderstanding.
If the breaks in _one_ version
Am 09.10.2014 11:27, schrieb David Kastrup:
Urs Liska writes:
Am 09.10.2014 10:44, schrieb David Kastrup:
Urs Liska writes:
And I would really love to see that being part of LilyPond itself and
not only possible to implement in a library.
Firstly because I would like *all* LilyPond users
Urs Liska writes:
> Am 09.10.2014 10:44, schrieb David Kastrup:
>> Urs Liska writes:
>>
>>> And I would really love to see that being part of LilyPond itself and
>>> not only possible to implement in a library.
>>> Firstly because I would like *all* LilyPond users to have that
>>> available and
Am 09.10.2014 10:44, schrieb David Kastrup:
Urs Liska writes:
And I would really love to see that being part of LilyPond itself and
not only possible to implement in a library.
Firstly because I would like *all* LilyPond users to have that
available and secondly because I would like to add th
Urs Liska writes:
> And I would really love to see that being part of LilyPond itself and
> not only possible to implement in a library.
> Firstly because I would like *all* LilyPond users to have that
> available and secondly because I would like to add this as a Layout
> Control Option to Fresc
Am 09.10.2014 10:27, schrieb d...@gnu.org:
On 2014/10/09 07:45:38, uliska wrote:
The patch works as expected.
However, it has to be noted that by default (that is, running without
the
option) *keeps* the tags.
Sure. So does \keepWithTag #'() \tag hi { c4 4 4 4 } (actually, before
the ex
On 2014/10/09 07:45:38, uliska wrote:
The patch works as expected.
However, it has to be noted that by default (that is, running without
the
option) *keeps* the tags.
Sure. So does \keepWithTag #'() \tag hi { c4 4 4 4 } (actually, before
the existence of \tagGroup it didn't).
When I de
Am 08.10.2014 00:30, schrieb nine.fierce.ball...@gmail.com:
On 2014/10/07 08:37:06, uliska wrote:
On 2014/10/07 08:37:06, uliska wrote:
On 2014/10/07 08:37:06, uliska wrote:
On 2014/10/07 08:37:06, uliska wrote:
Important:
* There should be regression tests.
OK. (but only *if* the patch sh
https://codereview.appspot.com/150670043/diff/1/Documentation/notation/spacing.itely
File Documentation/notation/spacing.itely (right):
https://codereview.appspot.com/150670043/diff/1/Documentation/notation/spacing.itely#newcode1857
Documentation/notation/spacing.itely:1857: @end lilypond
On 201
The patch works as expected.
However, it has to be noted that by default (that is, running without
the option) *keeps* the tags. When I define a command and encapsulate it
in a tag this command is executed unless explicitly switched off with
-dtags-to-remove.
https://codereview.appspot.com/14965
22 matches
Mail list logo
