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, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.