lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Syntax: lyric_mode_music might be a MUSIC_FUNCTION (issue 343820043


From: David Kastrup
Subject: Re: Syntax: lyric_mode_music might be a MUSIC_FUNCTION (issue 343820043 by address@hidden)
Date: Wed, 25 Apr 2018 23:14:04 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

address@hidden writes:

> On 2018/04/25 12:22:18, knupero wrote:
>
>
>> @Everyone: I won't bother you here any longer.
>
> Knut,
>
> It's not a bother.
>
> But it's important to recognize that the parser is a difficult system to
> work with, and we've had lots of problems over the years with lookahead
> not being handled properly.  So the issue that David raises here about
> lookahead is a real issue.
>
> Your proposal is to allow music functions enclosed in braced lists, but
> I don't know that there is anything in the parser that explicitly says
> it needs a braced list.

No, the proposal was to allow music functions _not_ enclosed in braced
lists as the music expression subject to \addlyrics .  His examples were
of music function calls where the last argument was brace-enclosed, but
the proposed syntax would have accepted music function calls without
such delimited arguments, switching back from lyrics mode at a point
where the next token already had been scanned in lyrics mode.

> I can see the value of having lyrics provided by a music function (for
> instance, if you want to sing solfege).

You can do that by using braces around the lyricmode expression
including the music function call already.  The proposal was to allow
this without braces.  Functionally, this is different since the
additional level of braces also creates an additional layer of
sequential music.  However, nesting several layers of sequential music
does not typically lead to different results since the wrapping
sequential music expression does not survive into the stream events
caused by iteration.

> It's just important to do it properly so it works well in the parser.
> And David has spent a lot of time trying to make the parser work in an
> explainable and predictable manner.  And this means that there are
> dozens of things that didn't work well in 2.14 that now are trivial to
> do in 2.19.
>
> So hang in there, and have the discussions, and I'm convinced there is
> a way to make both you and David happy.

I've already spelled out the approach that would be required for solving
that problem in a sound technical manner.  However, a "discussion"
requires a basic willingness to listen.  With Knut not considering
comments in the code and explanations in the mailing list and at the
same time acting indignant when feeling his competence is being
questioned, there does not seem an amicable way to bring him up to speed
on the parser internals without having to fight him for accepting any
bit of information.

This is very time-intensive, exhausting, draining, and unpleasant.  I
don't really want to spend my time in that manner, particularly if I
don't see this getting anywhere.  Now most certainly any colloborator on
the syntax would want initial coaching and I am willing to do my part in
that.  But not when this means a constant fight to get the other side
accept any bit of information or experience.

I very much doubt that there is a "way to make both [Knut] and David
happy" but I'd be willing to settle for a communication style allowing
for technically sound contributions to evolve without having an ugly
fight over every item.

> https://codereview.appspot.com/343820043/

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]