Good morning, Jean,
thank you very much for your detailed explanation! This helps me to
understands things a bit better.
Jean Abou Samra schrieb am 21.01.22 um 19:30:
Le 21/01/2022 à 08:57, Bernhard Fisseni a écrit :
- There is a point in processing when one has to convert every "line"
(in my example) to markup, although the interpretation happens
automatically in other places (see interpret-markup-list in
apply-last-strut).
I'm not sure what you mean here. Can you clarify?
What I meant was that while in the Lilypond source, one can have a top
\markup, which makes more or less all its argument a markup, when
writing the markup commands, one occasionally has to apply
(interpret-markup) or (interpret-markup-list) to inner arguments to
return the right type, e.g. in the recursive function I wrote. If I
understand correctly, one is doing piecewise evaluation "by hand". It
feels rather natural if one understands the general system, I suppose,
as there are these different explicit and implicit conversions of syntax
into markup. (If that is too cryptic, I am sorry; it is probably not
such an important point.)
I would agree that the explanations regarding markups vs. markup
lists, markup vs. stencils, markup in scheme etc. in the Documentation
might be improved.
For what it's worth, a step has been made
just a few weeks ago with
https://gitlab.com/lilypond/lilypond/-/merge_requests/1089
That merge request revised the Notation Reference
material about markups (though not the Extending
Manual material) so that the interplay between
markups and markup lists would be clearer. Part
of my motivation for doing this is that it took
myself ages even as a developer to discover the
way applying a markup command taking a markup as
last argument to a markup list as last arguments
"maps" it as in your examples.
Thank you, very much, I will have a look at it!
------------------------------------------------
Regarding the problem at hand, I believe it can
be solved by defining a slightly tweaked version
of \column that allows turning off the behavior
that avoids overlap between lines:
[...]
Thank you, that is also an interesting approach, and feels as if the
problem is resolved is "at a better place" in the command.
Again, thank you for your patience,
best regards,
Bernhard
