Re: Implement new markup-command combine-list (issue 264960043 by address@hidden)

[David Kastrup]

address@hidden writes:

> On 2015/08/31 10:27:04, dak wrote:
>
>> Ok, I've taken a look.  Markups are so undelimited in their nature
> that there is
>> not much of an option other than convert-ly actually knowing all
> markup commands
>> with their signatures.  That's doable but rather onerous.  In
> addition,
>> musicxml2ly uses the \combine command as well.
>
>> So we are likely better off with a new command name.  "\combines"
> would also be
>> a possibility but is probably too cute/confusing/unhyphenated.  Now if
> we
>> basically phase out \combine and replace most of its uses manually, it
> would
>> become an option just to use some _unrelated_ word.
>
>> Like \superimpose or \overlay or \collect or something other nice.
>> Or just keep the bikeshed in the originally proposed color.
>
> Thanks for your time looking into a possible convert-rule.
>
> I'm really tempted to delete old \combine and fixing all occurences in
> our source.
> Would it be an option to do a convert-rule outputting "Not smart enough
> to ..."? for a combine-command without a markup-list as argument?
> I seem to remember something like that has been done before.

It's been a really long time since we last did something like that.

> If that's not feasible or wanted, I'd prefer \combine-list, because it's
> descriptive (in a technical way) or \overlay, because there is a
> LSR-snippet providing the functionality already and some users may be
> used to it.
> http://lsr.di.unimi.it/LSR/Item?id=628
>
> What do people think?

I'd go for \overlay then.  The LSR snippet has slightly different
semantics: it excludes empty stencils and non-stencils and does not
return an empty stencil but at least a point-stencil, but all that are
decisions I don't consider a good idea for a general command.  It would
probably make sense to change the snippet to just do
(apply ly:stencil-add (interpret-markup-list layout props args))
until it's retired altogether.  That way we avoid entertaining competing
slightly incompatible definitions.

> https://codereview.appspot.com/264960043/

-- 
David Kastrup