David Zelinsky <d...@dedekind.net> writes:
> David Kastrup <d...@gnu.org> writes:
>
>> But while my desire for work on user-pointing and internal design and
>> architecture at that time sort of unfolded mostly in a vacuum, the years
>> since then have not seen a lot of uptake.
> [...]
>> There also is a lot of potential for making ping-pong progress. I
>> realize that I am not exactly the most fun person to be working with,
>> but also I tend to get stuck on boring or repetitive tasks to an
>> inordinate degree.
> [...]
>> So how to better involve others? The parser may be one of those areas
>> with an awful amount of shoestring and glue, namely fiddling around
>> until things happen to work. All that fiddling happens in private
>> before commits end up in master, meaning that it has no opportunity to
>> end up contagious the way it happens now.
>
> I've been interested in finding ways I can contribute to Lilypond,
> beyond the couple of minor merge requests I've had accepted. I don't
> know much about parsers. I read the dragon book years ago, and have
> written some seat-of-the-pants code that might qualify as parsing, for
> various things related to my math research, but nothing at all
> complicated or formal. And my experience with, say, bison, is that I've
> heard of it. :) But I'm comfortable reading documentation and happy to
> learn new things. And I have plenty of experience getting down into the
> weeds fiddling with things to get them to work just right.
>
> So if you're willing to have a bit of patience and point me in the right
> direction to learn things I need to know, I'm happy to help.
Well, I guess the first litmus test is taking a walk crossreading
lily/parser.yy and getting a feeling for what makes sense to you and
what makes your eyes glaze over.
A recent comparatively straightforward change had been
commit 276d688a358ff49e04b8b18e91ac15d56276cb62
Author: Jean Abou Samra <j...@abou-samra.fr>
Date: Sun Dec 18 18:27:24 2022 +0100
Accept bare pitches/durations as music arguments to markup commands
This adds a tiny bit of the smart argument handling music functions have to
markup commands. Namely, if a command expects a Scheme argument (i.e., the
predicate is not markup? or markup-list?), and { <pitch> } or { <duration>
} is
passed, the music interpretation as note event of those constructs is tried
as
well against the predicate. The most obvious use case is
\markup \rhythm { 8. }
Checking it out may be a hint about what a "comfort level" change not
involving an inordinate amount of shoestring and glue would like.
Probably the worst shoestring and glue department is how
function_arglist is destructured.
I may add some work-in-progress stuff to a branch soonish. I currently
have implemented the equivalent of define-music-function for pitches and
am mostly through with duration function (I am stuck on 4 reduce/reduce
conflicts at the moment that are essentially all the same problem).
This would warrant extending to book functions, score functions and a
few others. Most of those are likely trivial to do and don't offer a
lot (other than consistency and syntactic predictability) over
define-scheme-function.
So there are some candidates which are easy to implement in that
context, and some that are really tricky.
--
David Kastrup
