Re: Emacs lilypond mode

[David Kastrup]

Werner LEMBERG <address@hidden> writes:

>> David's suggestion, the GNU Emacs SMIE Simple Minded Indentation
>> Engine looks like a good place to start. For this I need the BNF
>> grammar for Lilypond.  Where does one find that?
>
> See Appendix A in the contributor's guide.

Of course, the grammar in there is by no means overly useful for that
purpose since

a) it is LALR(1) while SMIE is very simple since it should be parseable
backwards and forwards
b) it is actually not even true LALR(1) since it relies on lookaheads
and token pushbacks and other stuff to do its work.
c) its tokenizer converts music function calls into an interesting
sequence of tokens representing various predicates that are queried when
running

So there is no sane manner in which Emacs can employ the grammar in the
manual short of actually running the source code through a version of
LilyPond outputting its parsing decisions (like -ddebug-parser would).
While that sounds initially attractive, it requires syntactically valid
code and when editing code, indentation is required most of the time for
code that is not yet syntactically valid (because the tokens responsible
for undoing the indentation later on have not yet been entered).

So basically, one is dependent on faking a grammar.  Bonus points for
finding a generally useful way to represent music functions (or an entry
style where the users' intentions are expressed clearly enough that the
formatting engine does not mess with them).

I'd have stated that a good starting point if you like what Frescobaldi
does would be to translate its stuff into Elisp, but if your starting
point was that Frescobaldi was becoming to slow to be useful,
translating the code responsible for this slowness into Elisp is not
going to make things faster.

So basically, you have to mostly start from scratch.  I'd take inventory
of the tools Elisp offers, and I'd likely ask the Frescobaldi people how
they grew into the current usefulness.  And of course it may make sense
to find out what kind of functionality/approach caused the slowdown
making Frescobaldi unworkable to you.

This is by no means a small feat, and it requires developing a LilyPond
engine that basically formats based on cursory glancing.

The main nuisance I find with the current mode is that indentation obeys
some non-local heuristics, likely getting thrown off by Scheme and/or
#{/#} and once it is thrown off, it insists on making anything awful
even when 20 lines of hand-formatted code intervene to the location
throwing it off.  That's more obnoxious than anything else.

I doubt it is worth hunting in detail for the cause: starting from
something which is better to work with than entirely hand-written ad-hoc
code is likely better for future maintenance.  Thus my SMIE suggestion.

-- 
David Kastrup