lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Suggestion: Keep original breaks


From: Urs Liska
Subject: Re: Suggestion: Keep original breaks
Date: Wed, 27 Nov 2013 15:33:10 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0

Am 27.11.2013 14:54, schrieb David Kastrup:
Urs Liska <address@hidden> 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 there _are_ people who think that improving usability on that side actually improves LilyPond usage itself and may increase its acceptance. And this is _not_ a single-user opinion.


And it's a no-go to inject arbitrary code into to input files that
would either make scores dependent on Frescobaldi or on a separately
shipped library.
It's also a no-go to inject arbitrary code into LilyPond proper that is
artificially restricted to be only suitable for the shortcuts of a
single user's workflow.

That's bullshit.
I can see three modes of writing scores with LilyPond: creating from scratch, copying from models or generating algorithmically. I'm quite sure the last one has only a marginal share, and the other two may be more or less balanced. So entering conditional breaks is potentially useful for nearly half of LilyPond users. Keeping original breaks is more or less relevant, depending on type and complexity of the score, but if the commands were available like \break or \slurUp I'm sure _many_ people would use them regularly.

And it's not a shortcut but a means to avoid having to choose between creating dependency issues or having to repeatedly define basic behaviour. That's why one can't say I'm shouting down tag-based solutions.


Please read LilyPond's documentation about structuring input files and
try to imagine where such a personal minifeature would fit into the
documentation.

Of course nowhere because I'm not talking about structuring input files but about page layout. Documentation for my (admittedly mini) feature would painlessly fit in 4.3.1 ("Line breaking") and 4.3.2 ("Page breaking") of NR.

Urs




reply via email to

[Prev in Thread] Current Thread [Next in Thread]