Re: \mark and slur

[David Kastrup]

Thomas Morley <address@hidden> writes:

> 2017-09-15 0:25 GMT+02:00 David Kastrup <address@hidden>:
>> Thomas Morley <address@hidden> writes:
>>
>>> I'd go for post-event(s)
>>> Plural, because there may be more than one. See example below
>>
>> But every one gets its own warning, so each warning is only for one.
>
> Well, then I'd expect two warnings for:
> { \fermata -- d' }
> because two post-events are present.
> At least the following let me think that _two_ are there:
>
> foo =
> #(define-music-function (mus)(ly:music?)
>   (music-map
>     (lambda (m)
>       (if (music-is-of-type? m 'post-event)
>           (begin
>             (display-scheme-music m)
>             m)
>           m))
>     mus))
>
> \foo { \fermata -- d' }
>
> But I only get
> warning: Adding <> for attaching loose post-event
> {
>   \fermata -- d' }
>
> Which I take as _one_ warning.

Ah, you are right.  lily/parser.yy has

                bad = scm_cons (scm_car (post), bad);

instead of, say,

                bad = scm_append (scm_list_2 (post, bad));

It's only the first post-event which gets flagged with a warning right
now.

> Acknowlegged.
>
>> Frankly, what does it even _mean_ to use a
>> particular righthand finger and string for a non-existing note?
>
> Well, that hold as well for:
> { -1 -- d' }
> but this one works.

That's because historically you could do

<c e g>-1-2-3

and consequently _equivalently_

<< <c e g>
   s-1-2-3 >>

either of which do the formatting differently from <c-1 e-2 g-3>, using
the Fingering_engraver rather than the New_fingering_engraver .

But this historic crap is so unrelated to issue 5181 that I am not
interested in discussing or addressing it in this context.  Issue 5181
does not touch it.

>>> Your patch-descriptions reads (among other stuff):
>>>
>>> "Parser: Add reverse_music_list function
>>>
>>> This function does not just reverse a music list but also integrates
>>> post events into the respective preceding expressions. If that is not
>>> possible, a warning is printed and they are either dropped or attached
>>> to an empty chord (depending on a call parameter).
>>> "
>>>
>>> So I'd rather expect a warning if stuff is dropped.
>>
>> It isn't.  Please take a look at the output of \displayMusic .  It is
>> not _dropped_ but rather ignored since no engraver listens for those
>> events and they aren't attached to notes where the
>> New_fingering_engraver would get to consider them.
>>
>> They are part of the expression, as announced.
>
> Ok, I've read "dropped" as dropped from printing, so this was sort of
> misunderstanding on my part.

Well, this _is_ the parser.  It's separate from turning stuff into print
or to Midi.  Stuff that fails to appear in print is admittedly not
really popular with users and probably more surprising than stuff that
fails to appear in Midi.  The situation is better than it was in 2.12
(?) and has not changed recently.

-- 
David Kastrup