Re: Snippet: Customizing markFormatter

[Aaron Hill]

On 2019-03-22 1:32 am, Valentin Villenave wrote:
> On 3/21/19, Aaron Hill <address@hidden> 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