Urs Liska <u...@openlilylib.org> writes: > Am 16.05.2014 09:41, schrieb d...@gnu.org: >> >> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
