Re: preliminary GLISS discussions

[David Kastrup]

Jan Nieuwenhuizen <address@hidden> writes:

> David Kastrup writes:
>
>>> Maybe the time has finally come to drop convert-ly and implement and
>>> fully supported conversions using LilyPond on music stream level.
>>
>> You still need a parser of the appropriate version at the front end.
>
> We have perfectly fine ly parsers of each available version available in
> executable form from lilypond.org.  What we do not yet have, is a handy
> or integrated way of dumping the music tree with the original binary
> [read: a nice web service -- this could possibly be integrated with a
> mutopia revival, I'll be looking into this] reading the music tree with
> the current version and a perfect ly-dump function.  Eg, I think we may
> want to preserve %-comments in the music tree, or other stuff the user
> does not want to lose?

For an emergency conversion web service of an archive in case of
convert-ly failure, a Scheme-written package diverting all required
hooks like toplevel-book-handler, toplevel-bookpart-handler,
toplevel-score-handler, toplevel-music-handler, toplevel-text-handler
could likely be written.  The meaning of spacing variables would need
conversion, some overrides likely as well, context definitions and stuff
would be a bit tricky to properly detect (but one could just start out
with empty context/output defs and consider every change as relevant),
but as an emergency measure, I consider the likelihood of getting at
least something useful out for a majority of scores when run on the
respective original version of LilyPond reasonably high.

It would work at the music expression level, not at the stream event
level: the latter has already lost too much information.

All the input syntax/music function folderol would not be an issue since
those have already done their work at the time of calling the handlers.

Markup functions might be more tricky.

-- 
David Kastrup