lilypond-devel
[Top][All Lists]
Advanced

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

Re: Issue 3918: Add \alternatingTimeSignatures (issue 97110045)


From: David Kastrup
Subject: Re: Issue 3918: Add \alternatingTimeSignatures (issue 97110045)
Date: Sat, 17 May 2014 08:59:22 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

Urs Liska <address@hidden> writes:

> Am 16.05.2014 09:41, schrieb address@hidden:
>>
>> Well, we have \omit already.  What if we had
>> \appearance [markup] [grobname or music]
>>
>> Which would basically be the syntactic sugar for overriding the stencil
>> with an appropriate grob-interpret-markup?
>>
>> That way one could just define some markup function for formatting time
>> signatures and use it either in markup contexts or indeed for overriding
>> a time signature.
>
> If I understand you correctly this would mean that one would write
>
> \appearance \fractionList #'((6 8)(5 4)) Score.TimeSignature
>
> instead of
>
> \override Score.TimeSignature.stencil = \fractionList #'((6 8)(5 4))
>
> ?
> If yes, then I' consider this an improvement because "overriding the
> stencil" is frightening to new users, I can tell you ...

No, it would be more like
\appearance \markup \fraction-list "-" #'((6 8)(5 4)) Score.TimeSignature

assuming that fraction-list takes two arguments, namely one separator
markup (not sure whether we can format this markup with settings where
at least "", "-", and "/" come out nicely without further tweaking) and
the numeric data.  Which is sort-of straightforward to puzzle together,
but it would still warrant creating a shortcut when actually used.  It's
just that the building blocks for creating the shortcut would all be
available.

> The name should be a verb, though, not a noun.

Ah yes.

> But if I'm not mistaken this isn't relevant to the current patch.

Yes and no.  The question is when we have apparently a large set of
different uses whether it even makes sense to give a predefined
definition for one particular use case rather than something more
general.

> My question about appearance of the hyphen means:
>
> We have a function to create the markup used to override the stencil.
> _Inside_ that function we have code to draw the hyphens, and this uses
> hardcoded values for length and thickness as well as the padding of
> the hyphen. It would be nice to override the used values without
> having to supply them to each function invocation.

Well, if you are supposed to create your own definition from markups, of
course you would define your markup appropriately.  I don't think that
one would use different settings in the same document.

Basically the question is "if we had something like \appearance in
general use, would that give us a situation where we'd choose a
different interface for this problem?".

If the answer to that is "not really", then this isn't relevant to the
current patch.  I'm not overly happy with the tradeoff between
generality and usability for this proposal.  There is a lot of "there
are other similar use cases which this will not be useful for" in here,
but of course that's still better than "now this is so complex that
nobody will use it anyway".

-- 
David Kastrup



reply via email to

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