Currently filetypes are either built-in or custom. 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.
Custom: second class poor cousin filetype that is a customisation of existing filetypes and must use existing filetypes lexers or parsers. Since its only a data file a user can use it with an existing Geany release but with the inherent limitations. What would be a better solution would be something that is a combination, so that an existing Geany can load a new full capability filetype. This proposal is to consider reorganising the filetype specific code to a loadable DLL, with the lexer, the parser, the support data (eg highlighting), a filetype specific version of each of the functions that depend on filetype and whatever other filetype specific items there are. Then if a file that uses that filetype simply loads the filetype DLL (if not already loaded). The version of Geany and the available filetypes is therefore decoupled. Someone who is developing a new filetype only has to host the DLL which a user could try (at least for major platforms), rather than having to host a fork of Geany that the user has to know how to build and install themselves. I am not saying there may not be some "interesting" changes, moving the highlighting mappings from a `.h` file to a callable function in the DLL comes to mind, but I can't see it as impossible. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/3970 You are receiving this because you are subscribed to this thread. Message ID: <geany/geany/issues/[email protected]>
