lilypond-devel
[Top][All Lists]
Advanced

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

Re: Suggestion: Keep original breaks


From: David Kastrup
Subject: Re: Suggestion: Keep original breaks
Date: Wed, 27 Nov 2013 14:54:47 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Urs Liska <address@hidden> 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 reflect a
single tag/setting?

Sorry, but that's not a "wider audience" we are talking about.  That's
not even a use case, but it is rather saving very few characters of
typing for a very idiosyncratic work flow.

> And this just is nicer if it is directly accessible than if it is just
> feasible.  \slurUp wasn't necessary either - you can easily define it
> yourself as \override Slur #'direction = #UP.

But there are just three slur directions, and there are a multitude of
possible tags one can use.  Tags are exactly there for selecting
document variants.  And yet you try to shout anything based on tags
down.

> What I actually want is to add that behaviour as an option to
> Frescobaldi's Layout Control Mode.

So what?

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

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

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.

-- 
David Kastrup



reply via email to

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