I agree in theory that's something that looks nice, and I wanted to try out at some point -- but it's not a trivial task. IIRC @techee doesn't love it because it's unnecessay (code and memory overhead is low) and inefficient (loading overhead and management is not negligible), but well :)
Well, the main reason I don't love it because I think there's a better way to handle this:
Built in: physically compiled into Geany, lexer if used, parser if used, added to a number of other functions throughout Geany for example highlighting_is_string_style() or highlighting_is_comment_style() or editor_get_filetype_at_line() or lexer_has_braces() and many more. A user has to get a recompiled Geany to use a new filetype, so effectively at a new release.
I would prefer to have all these settings configured dynamically in a config file at which point everyone (who doesn't know C and how to create the DLL) would be able to experiment with the settings and create a filetype. Of course this requires that there's the necessary lexer in Geany. We could handle it in two ways:
For ctags parsers I think we are in a better position to get the configuration right so better if we do it by ourselves (and I think the hard-coded configuration is just fine here, I wouldn't make users mess with that much). Also, the ctags features are now somewhat duplicated by LSP so ctags support might not be so critical for users if the LSP server exists.
So I'd spend the limited efforts we have on making it possible to add language support to everyone by the means of config files rather than the few people who know C, the target language they want to add, study Geany API, and manage to create the DLL - at the end I'm afraid it will be just us ;-)
(Also consider the extra API/ABI surface to maintain when such loadable language support libraries are introduced.)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.