Re: \justify & break

[Gianmaria Lari]

Thank you David for the details.

G.

On 5 October 2017 at 10:44, David Kastrup <address@hidden> wrote:

Thomas Morley <address@hidden> writes:

> 2017-10-05 9:32 GMT+02:00 Gianmaria Lari <address@hidden>:
>> On 5 October 2017 at 09:28, Thomas Morley <address@hidden> wrote:
>>>
>>> 2017-10-05 6:56 GMT+02:00 Gianmaria Lari <address@hidden>:
>>>
>>> > By the way why \justify-string use the scheme syntax and it is not a
>>> > first
>>> > class citizen of lilypond language?
>>>
>>> Not sure what you mean. I don't know what a "first class citizen of
>>> lilypond language" might be.
>>
>>
>> Why \justify-string use the scheme-syntax and not the lilypond syntax?
>
> You probably mean why the # is requiered?
>
> Well, historically most arguments in lilypond needed to be prepend by #.
> Due to much work, mostly by David Kastrup, we nowadays can omit the #
> pretty often. But markupmode is a special thingy. Most kinds of
> arguments still need it and all strings, even:
> \markup \simple #"foo"
> Can't say more without diving deep into the source-code.
> David?

Markup mode has not been touched and is a mess of its own.  Basically it
knows the predicates "markup?", "markup-list?", and everything else,
"scheme predicates".

Still, there is no real point in not just accepting a quoted string for
scheme predicates: that does not really open much of a can of worms.
However, things become a lot murkier with unquoted strings/words (should
they be made to match a symbol-only markup command predicate?), and
unquoted strings have not been distinguished from quoted ones until
recently.  Once one works with "polymorphic" input matched to
predicates, the interaction with the markup macro and possible markup
compilation becomes unclear (markups are parsed at a different time than
they are interpreted).

Also argument predicate polymorphism is incompatible with a recent
change allowing Scheme predicates to receive { ... } arguments with
semantics equivalent to that of ##{ ... #} .  That's a 2.21 change and
up for probation, but it is basically incompatible with markup list
arguments of the form { ... } getting interpreted using the kind of
dynamic checking that allows music functions to see -1 as number or post
event, depending on what the music function expects, or "xx.xx" as
symbol list when needed.

So basically, there is a whole lot of related matter hanging around it.
Making quoted non-Scheme strings acceptable for arguments of type
string? should be feasible these days.  I don't think this would cause
conflicts in syntax.  It's also not much of an improvement.

--
David Kastrup