2017-09-15 0:25 GMT+02:00 David Kastrup <d...@gnu.org>:
> Thomas Morley <thomasmorle...@gmail.com> 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.
>
>> But
>> { -\3 -\rightHandFinger #2 d'4 }
>> issues the warning, the image doesn't contain the post-events, though.
>> Not a problem of your patch, because a spelled out version fails as well:
>> { <>\3\rightHandFinger #2 d'4 }
>>
>> I guess it's because the post-events are attached to an event-chord
>> and not a note-event, since
>> { d'4\3\rightHandFinger #2 }
>> works as expected. But I'm guessing...
>>
>> Nevertheless, the current warning feels like lily would fix the
>> problem, but doesn't.
>
> It fixes the problem of post-events attached to nothing.
Ok, understood.
> Try
> \displayMusic if you don't believe it.
I did :)
>
> The "problem" of explicit per-note articulations (like string and
> right-finger numbers) not getting engraved when attached to a whole
> chord has always been there. That they _do_ appear for
> { d'4\3\rightHandFinger #2 } has not been historically the case. It's
> the somewhat edgy
>
> commit 84cad110c3bbaeca8e5144dba7f8756b89100396
> Author: David Kastrup <d...@gnu.org>
> Date: Sat Apr 21 22:30:55 2012 +0200
>
> Let rhythmic-engraver make its articulation-or-event decision based on
> current listeners
>
> This removes the dependency of the rhythmic engraver on a static list
> of unlistened event classes and thus is part of work on issue 2449.
>
> As one effect, string numbers on isolated notes in Voice contexts are
> now typeset by default since the string numbers have no listener in
> Voice contexts even though they would have one in TabVoice.
>
> and similar which does that.
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.
>
>> 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.
Cheers,
Harm
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
