The approach used by many editors/IDEs is to support the Language Server Protocol which allows the editor/IDE client to query information equivalent to that provided by the lexers and parsers from a server process.

Most editor/IDEs expect "somebody else" to provide the server, usually the language project. But in return the language gets support from all editor/IDEs that support LSP and the editor/IDEs get likely better support since the language project may use parts of its implementation, eg clangd uses the clang compiler guts.

Initial examination has shown that supporting LSP in Geany is a major redesign and implementation, so nobody has the effort to commit to it. Also querying an external process is slower, resulting in delays for some functions unless Geany becomes asynchronous, which means more redesign.

But IIUC the LSP only provides the tokens, it doesn't specify the mapping to styles (colour, font, background etc). So each editor/IDE still has its own method of specifying that mapping which is complicated by support for "themes". These can be expressed in .ini files, JSON files, custom files etc depending on the editor. So no perfect solution yet 😁

There are two problems with regex based syntax colourisers like your example:

There are very few serious programming languages that have a context free syntax, let alone context free semantics. So the result is sometimes wrong.
They are generally slow, try opening a large HTML in Gedit vs Geany and see the difference in the time to colouring. Now consider how annoying that delay will be between keystrokes.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.