[email protected] 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 _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
