Re: [GLISS] Existing syntax abominations

[David Kastrup]

Janek Warchoł <address@hidden> writes:

> On Fri, Sep 21, 2012 at 11:25 PM, Trevor Daniels <address@hidden> wrote:
>>
>> David Kastrup wrote Friday, September 21, 2012 5:46 PM
>>> Well, the host of different syntaxes to \tempo aside, here are some
>>> other nuisances:
>>> [snip]
>>> Look and behold: after the closing brace of the sequential music, the
>>> expression is not finished because LilyPond has to see whether there is
>>> an \addlyrics after that, as it would become part of the expression.
>>>
>>> So \addlyrics is on my blacklist of unnecessarily surprising constructs.
>>
>> I take the point, but it would be a shame to ditch \addlyrics.  I'm sure
>> many users setting simple songs use this construct.
>
> I think David doesn't meant that we should remove \addlyrics
> whatsoever.  I suppose that \addlyrics would just have to be
> redesigned.  David, am i right?

It would make some sense.  At the current point of time, \addlyrics can
be attached to pretty much any music, and it takes a wild guess at call
time what kind of context it should attach itself to with what
structure.

Like with << ... \\ ... >> it would make more sense to just package
\addlyrics as a particular, recognizable music element, and then use a
post-processing stage rather than the parser to put it into context.

Take a look at the difference in output for

xxx = { c'2 c''4 c'' << r1 \\ r1 >> } \addlyrics { O- san- na }

\void \displayLilyMusic \xxx

sc = \score { \xxx }

\void \displayLilyMusic #(ly:score-music sc)

The difference becomes quite more apparent (but unwieldy) when using
\displayMusic rather than \displayLilyMusic.  If \addlyrics would work
via that mechanism, it would no longer require any special syntax at
all, and its hit-or-miss rate for picking the right context might
improve.

-- 
David Kastrup