Re: Suggestion: Keep original breaks

[David Kastrup]

Urs Liska <address@hidden> writes:

> 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.

Can we skip the ad hominem attacks?  They are no substitute for running
out of arguments.  Thanks.

>>> 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.

And you want to have only a single condition for making them
conditional, and you don't want to combine this with other tagging in
the score, and you want hardwired commands that only listen to the
equivalent of a single tag.

That's artificially restricted.

> 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.

So what's wrong with them?

>> 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.

So you want to have the functionality of a single tag, only called
differently, explained in a different context, not useful in combination
with anything else, and given special commands.

While it would be perfectly feasible to make this fit into a larger
scheme comfortably.

I'm not interested in adding special cases when one can perfectly well
do this in a straightforward and flexible manner.  One could probably
even take your use case as illustration in the manual, assuming the
underlying general mechanisms for accessing tags from the command line
are there.

-- 
David Kastrup