On 11/27/2013 04:32 PM, Urs Liska wrote:
Am 27.11.2013 16:25, schrieb Carl Sorensen:
On 11/27/13 8:04 AM, "David Kastrup" wrote:
Urs Liska writes:
[...]
originalBreak =
#(define-music-function (parser location)()
( #{ \tag #'keep-original-breaks \break #} ))
[...]
If the general case we
Urs Liska writes:
> Am 27.11.2013 15:52, schrieb David Kastrup:
>> Urs Liska writes:
>>
>>> Am 27.11.2013 14:54, schrieb David Kastrup:
Urs Liska writes:
> What I actually want is to add that behaviour as an option to
> Frescobaldi's Layout Control Mode.
So what?
>>> I kn
Am 27.11.2013 15:52, schrieb David Kastrup:
Urs Liska writes:
Am 27.11.2013 14:54, schrieb David Kastrup:
Urs Liska writes:
What I actually want is to add that behaviour as an option to
Frescobaldi's Layout Control Mode.
So what?
I know you don't care about usability features involving g
On 11/27/13 8:45 AM, "Urs Liska" wrote:
>Am 27.11.2013 16:36, schrieb Carl Sorensen:
>> On 11/27/13 8:32 AM, "Urs Liska" wrote:
>>
>>> For me this sounds good.
>>> Requiring to write \include "original-breaks.ly" is significantly
>>>better
>>> than requiring to define the commands.
>>> But it
Am 27.11.2013 16:52, schrieb David Kastrup:
Urs Liska writes:
Am 27.11.2013 16:36, schrieb Carl Sorensen:
On 11/27/13 8:32 AM, "Urs Liska" wrote:
For me this sounds good.
Requiring to write \include "original-breaks.ly" is significantly better
than requiring to define the commands.
But it
Urs Liska writes:
> Am 27.11.2013 16:36, schrieb Carl Sorensen:
>> On 11/27/13 8:32 AM, "Urs Liska" wrote:
>>
>>> For me this sounds good.
>>> Requiring to write \include "original-breaks.ly" is significantly better
>>> than requiring to define the commands.
>>> But it would still need a separat
Am 27.11.2013 16:36, schrieb Carl Sorensen:
On 11/27/13 8:32 AM, "Urs Liska" wrote:
For me this sounds good.
Requiring to write \include "original-breaks.ly" is significantly better
than requiring to define the commands.
But it would still need a separate switch, presumably through the
command
On 11/27/13 8:32 AM, "Urs Liska" wrote:
>
>For me this sounds good.
>Requiring to write \include "original-breaks.ly" is significantly better
>than requiring to define the commands.
>But it would still need a separate switch, presumably through the
>command line.
This is true, but it would be po
Am 27.11.2013 16:25, schrieb Carl Sorensen:
On 11/27/13 8:04 AM, "David Kastrup" wrote:
Urs Liska writes:
But also in this case I would come back and suggest including functions
like
originalBreak =
#(define-music-function (parser location)()
( #{ \tag #'keep-original-breaks \break #}
On 11/27/13 8:04 AM, "David Kastrup" wrote:
>Urs Liska writes:
>
>>
>>
>> But also in this case I would come back and suggest including functions
>>like
>>
>> originalBreak =
>> #(define-music-function (parser location)()
>> ( #{ \tag #'keep-original-breaks \break #} ))
>>
>> in LilyPond so th
Urs Liska writes:
> Am 27.11.2013 15:01, schrieb David Kastrup:
>> David Kastrup writes:
>>
>>> I see nothing wrong with giving a command line option for setting
>>> tags. That sounds useful, and it would most certainly encompass your
>>> use case. It would also fit into LilyPond's current too
Urs Liska writes:
> Am 27.11.2013 14:54, schrieb David Kastrup:
>> Urs Liska writes:
>>
>>> What I actually want is to add that behaviour as an option to
>>> Frescobaldi's Layout Control Mode.
>> So what?
>
> I know you don't care about usability features involving graphical
> tools such as Fres
Am 27.11.2013 15:01, schrieb David Kastrup:
David Kastrup writes:
I see nothing wrong with giving a command line option for setting
tags. That sounds useful, and it would most certainly encompass your
use case. It would also fit into LilyPond's current tool set, and
consequently into the doc
Am 27.11.2013 14:54, schrieb David Kastrup:
Urs Liska writes:
What I actually want is to add that behaviour as an option to
Frescobaldi's Layout Control Mode.
So what?
I know you don't care about usability features involving graphical tools
such as Frescobaldi, Denemo or whatever. But ther
David Kastrup writes:
> I see nothing wrong with giving a command line option for setting
> tags. That sounds useful, and it would most certainly encompass your
> use case. It would also fit into LilyPond's current tool set, and
> consequently into the documentation.
The way one would do that
Urs Liska writes:
> I'm not talking about pushing something into LilyPond just for my
> personal convenience but about adding a usability feature for a wider
> audience.
Breaks, and only breaks, that have a special command that can be
disabled from the command line, and that can in practice only
Am 27.11.2013 12:25, schrieb David Kastrup:
Urs Liska writes:
Of course I can achieve the same with tags. But there will be many
instances where I don't "need them anyway" because I don't really
care about the state of the original score except for this
simplification while inputting/proofing
Urs Liska writes:
> Of course I can achieve the same with tags. But there will be many
> instances where I don't "need them anyway" because I don't really
> care about the state of the original score except for this
> simplification while inputting/proofing.
So what? Why hard code one particul
Am 27.11.2013 11:48, schrieb David Kastrup:
Urs Liska writes:
I would like to suggest an enhancement in the handling of line breaks
that is useful for copying scores from existing models.
Currently LilyPond can decide about breaks herself or we can manually
force or prevent breaks.
But when co
Am 27.11.2013 11:55, schrieb Trevor Daniels:
Urs Liska wrote Wednesday, November 27, 2013 10:30 AM
I would like to suggest an enhancement in the handling of line breaks
that is useful for copying scores from existing models.
I suggest a command line option -dkeep-original-breaks for this switc
Urs Liska wrote Wednesday, November 27, 2013 10:30 AM
> I would like to suggest an enhancement in the handling of line breaks
> that is useful for copying scores from existing models.
>
> I suggest a command line option -dkeep-original-breaks for this switch.
> That way the user can add that op
Urs Liska writes:
> I would like to suggest an enhancement in the handling of line breaks
> that is useful for copying scores from existing models.
> Currently LilyPond can decide about breaks herself or we can manually
> force or prevent breaks.
> But when copying from or proof-reading against a
Hi all,
I would like to suggest an enhancement in the handling of line breaks
that is useful for copying scores from existing models.
Currently LilyPond can decide about breaks herself or we can manually
force or prevent breaks.
But when copying from or proof-reading against an existing score i
23 matches
Mail list logo
