Please include the Scintilla-Lexers for the Nim-language into Geany. As of now one uses the Python-Lexer and -Parser. There are two Lexers for Nim called "LexNim" and "LexNimrod". Both seem to be about 2-yrs old. "LexNimrod" was provided by the creator of Nim. I'd ask which of the two Lexers are more up-to-date. thx Andreas
AFAICT Notepad++ just uses the Lexilla lexer.
Thing is "somebody" who wants it has to make a pull request to create a Geany built-in filetype for it. The best example to follow is the most recently added Julia filetype https://github.com/geany/geany/pull/2584 (although it also adds symbol parsing via the uctags parser, so nim would be simpler)
Do we have something like generic syntax? That is like, if someone builds an editor, people could just re-use that?
It seems as if the editors like staying incompatible to one another. I recall the odd syntax getting the editor nano to support different file types.
For instance, for nano, to support .rb files, I have code such as this:
# ========================================================================= # # Escape codes # ========================================================================= # color red "\[0-7][0-7][0-7]|\x[0-9a-fA-F][0-9a-fA-F]|\[abefnrs]|(\c|\C-|\M-|\M-\C-)."
# ========================================================================= # # Expression substitution # ========================================================================= # color red "#{[^}]*}|#[@$]\w+"
Would be great if we could have automagic support for ALL custom programming languages in a unified way, rather than requiring of people to all write support for a particlar lexer or parser.
The approach used by many editors/IDEs is to support the [Language Server Protocol](https://microsoft.github.io/language-server-protocol/overviews/lsp/overview/) 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 :grin:
There are two problems with regex based syntax colourisers like your example:
1. There are very few serious programming languages that have a context free syntax, let alone context free semantics. So the result is sometimes wrong. 2. 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.
github-comments@lists.geany.org