Re: [GSoC] Proposal: Modular LilyPond Parser (C++)

"C. Stroppel" <[email protected]> Fri, 5 Jun 2026 22:27:52 +0200
Newsgroups gmane.comp.gnu.lilypond.devel
Message-ID <[email protected]>
> The parsing done by available Emacs modes right now is dissatisfactory.
> Other IDE support also would benefit from good and fast parsing.
> Frescobaldi does a comparatively nice job but that does not mean that
> there isn't potential for improvement.
>
First of all, I want to say that I use Frescobaldi a lot and with great gr=
atitude!
Nevertheless, I have managed to add some features to my own highlighter
in the meantime. For instance, it displays errors if a command is used
in the wrong context, or if expected arguments are missing.

> The problem with your project is that you want it to land in a space
> where it is thoroughly used by a community that always has a large
> interest in keeping its development going.  That is tricky to plan for
> in a reliable manner, so there is always the question how to move best
> such that your project's fate evolves from being bound to a single
> person.  Not all factors here are easy to plan for.
>
>
>
Maintenance seems incredibly easy to me when it comes to adding new comman=
ds or limited syntax changes.
Through the specification, the smart lexer reads something like this:Liter=
al     Allowed Context     Expected Arguments           =20
Musik-Event=20
=2D-----------------------------------------------------------------------=
=2D-----------=20
"\time"     Voice          number slash number           =20
time-signature-event "\key"      Voice _n_ame scale               =20
key-change-event "\times"    Voice          Nnumber slash number=20
music        time-scaled-music "\override" Score, Staff...    [ context=20
. ] object property =3D value   override-property

The specification is, so to speak, the actual program and corresponds to|l=
exer.ll|  and|parser.yy|.
My lexer is equivalent to Flex and Bison, just programmed more simply,
and hopefully faster and soon capable of incremental parsing.
I hope that the specification is so easy to maintain that you all could=20
extend it yourselves. In fact, the very reason I reached out to this=20
mailing list was to ensure that the fate of my project does not depend=20
on me alone. Therefore, I would like to send you a few questions under the=
 new subject line:
Questions regarding Specification ans Lexer.

Best regards,
Christian