On 2019-03-22 1:32 am, Valentin Villenave wrote:
On 3/21/19, Aaron Hill <lilyp...@hillvisions.com> wrote:
In an attempt to hide the Scheme-ness of the above approach, I put
together the following music function which replaces placeholder
strings
within the provided markup with the output of the specified formatter
function:
Hi Aaron,
I like what you’re doing! I wonder, though, if there couldn’t be a way
of ``hiding the Scheme-ness’’ without having to add a whole new
function. Besides, \set <property> = <value> is not something we
necessarily want to hide.
That is a fair point. It would be easy enough to change
\customMarkFormatter so that the \set must appear outside:
%%%%
customMarkFormatter = #(define-scheme-function (markup) (markup?)
(define (handle-formatter mark context markup)
(let* ((sym (and (string? markup)
(string-prefix? "format-mark" markup)
(string->symbol markup)))
(proc (and sym (defined? sym) (primitive-eval sym))))
(if (procedure? proc) (proc mark context) markup)))
(define (markup-fixup mark context markup)
(if (list? markup)
(map (lambda (elem) (markup-fixup mark context elem)) markup)
(handle-formatter mark context markup)))
(lambda (mark context) (markup-fixup mark context markup)))
% ...and later on... %
\set Score.markFormatter = \customMarkFormatter
\markup \rotate #30 format-mark-circle-numbers
%%%%
In other words, I dream of having the ability to do just:
\set Score.markFormatter = \markup \italic \etc
The tricky thing with \etc as a pattern is that it presumes something
fundamentally singular. While this aligns to the existing formatters
which only emit one string, someone might want to have rehearsal marks
that also include the current bar number. The formatter ideally should
provide the ability to reference multiple contextual properties.
Side note: I do think \etc could be beneficial in a more general sense
with markups and stencils. It is sometimes the case that folks desire
to augment an existing stencil rather than completely replace it.
Thankfully, grob-transformer is a useful tool for supporting this
strategy. A nice shortcut would be to use \etc as the placeholder for
the original stencil, and perhaps its presence could be detected and the
equivalent usage be automatically generated:
%%%%
\tweak stencil \markup \box \etc
% ...turns into... %
\tweak stencil #(grob-transformer 'stencil (lambda (grob orig)
(grob-interpret-markup grob #{ \markup \box \stencil $orig #})))
%%%%
Now, the current "formatter" functions act in two ways: translating
(determining whether marks should be expressed as roman/arabic
numbers, upper/lower case letters including "i" or not) and formatting
(do we want marks to be circled or boxed or italicized or whatever). I
think it would be saner to separate the two:
\set Score.markFormatter = \markup \box \italic #uppercase-letter-etc
\set Score.markFormatter = \markup \circle #arabic-number-etc
I used # instead of \ to clearly illustrate that the last item is not
a markup function, but it could (should) be otherwise.
This pattern resolves the issue I mentioned before, as one is able to be
explicit about which translated property (or properties) they would like
to insert and where.
Would you agree with such a solution? (Regardless of how we implement
it.)
At the end of the day, I am always for separation of concerns.
On 2019-03-22 1:44 am, David Kastrup wrote:
We probably should just extract the respective context variables and
put
them in the markup property list for whatever markup command wants to
use them, like we do with title fields.
Would that be something like: \fromproperty #'score:rehearsalMark ?
In terms of extracting variables, is this something that can be done
automagically for all properties? Or does it necessitate manual
selection?
My concern would be that what entails "the respective context variables"
might end up being too constrained. Currently, rehearsalMark and
currentBarNumber are probably the only practical variables to extract;
but who knows if there isn't something else that could find usefulness
down the road.
-- Aaron Hill
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
