Re: Frescobaldi?

[Jean Abou Samra]

> I’m wondering if the Frescobaldi approach is actually working out. Keep in 
> mind that originally Frescobaldi was just a project for adding support for 
> Lilypond to KATE, then it became a KDE parts solution, then it started to do 
> everything itself for more control. And this means you’ll need to maintain and
> develop many components for a niche community. Frescobaldi is essentially a 
> full text editor, solely for Lilypond. And I do not think the Lilypond 
> community is the best place for maintaining a whole text editor.
> 
> This also means you get a weird dependency situation which is hard to 
> maintain. Frescobaldi has a lot of qt-independent functionality, including a 
> reduced Lilypond parser and transformation tools and stuff. And it has a lot 
> of 
> interface stuff. This is the part that depends on qt5, and only one component 
> depends on the poppler integration.
> 
> So maybe instead of trying to maintain this collosus of tools it could make 
> sense to split it up into different parts:
> 
> → An LSP server
> → A transformative toolset
> → An editor using these features
> 
> This way no matter what might happen to Frescobaldi, much of the functionality
> would be still usable. With an LSP server any modern text editor with an LSP 
> client could benefit from understanding Lilypond syntax. And being able to a 
> toolset would make extending editors much more fun.
> 
> And this way the maintainance effort could be split. Maybe the LSP could even 
> become part of Lilypond itself (no need to implement a new parser if you 
> already have one), keeping it always up to date (rather than the always 
> outdated approch we have with Frescobaldi).


Well, what you call the "transformative toolset" is already separated, in the
form of the python-ly package. An LSP server might be nice, but it wouldn't
really take off that much functionality from Frescobaldi. I'd have to check
how advanced the LSP protocol exactly is now, but you definitely can't do
things like the MIDI player, the fonts dialog, or the manuscript viewer through 
LSP.

And of course, if we already have trouble maintaining the software as it is,
finding people to work on that kind of split is not going to be easier :(

Also, you cannot really use the LilyPond parser because it won't parse
LilyPond code without also interpreting it at the same time (e.g., music
functions can be defined dynamically). You don't want to pay the price
of parsing the full file every time a character changes, and you don't
want to lose syntax highlighting as soon as there is a syntax error.

signature.asc
Description: This is a digitally signed message part