On 2015/08/30 12:08:29, dak wrote:
On 2015/08/30 12:02:14, thomasmorley651 wrote: > On 2015/08/30 11:44:52, dak wrote: > >
https://codereview.appspot.com/264960043/diff/1/scm/define-markup-commands.scm
> > File scm/define-markup-commands.scm (right): > > > > >
https://codereview.appspot.com/264960043/diff/1/scm/define-markup-commands.scm#newcode1758
> > scm/define-markup-commands.scm:1758: (define-markup-command
(combine-list
> layout > > props args) > > For better or worse, we don't have other commands of *-list form.
Commands
> that > > _deliver_ a markup list are usually named *-lines for whatever
reason. But
> this > > command delivers a single markup. I don't have a better proposal
though.
> > I thought about deleting old \combine,
Yes, that sounds like a sensible path forward.
>but too much user-code relies on it. > Apart from not knowing python I really have no clue how something
like the
below > could be caught by a convert-rule: > > \markup { > \combine > arg1 > \combine > arg2 > \combine > arg3 > arg4 > } > > and transformed to: > > \markup \combine-list { arg1 arg2 arg3 arg4 }
Probably more doable than recognizing a single markup reliably. I'd
have to see
how well this works.
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. https://codereview.appspot.com/264960043/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel