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.
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 :)
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:
1. Include all the lexilla lexers (but possibly including unnecessary code and making the binary too big) 2. Include lexers on demand, or precisely, when someone asks for some language support and the lexer exists in lexilla, add it and say "we did our job, it's your turn to create the necessary configuration". Even if the guy actually doesn't do anything, the lexer could stay in case someone does it in the future. This will still make the the binary much smaller than in (1) and we'd know we include lexers for languages for which there's at least a remote interest.
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.)
Agree with @b4n its lots of work, maybe it will be part of the total re-write for GTK4? Not sure I agree with @techee its much overhead for a DLL if only filetypes that are used are loaded.
Agree with @techee that lots of the functions can easy be .conf file instead of hard coded. All that is needed is an extension of more sections in the filetype config file that expresses a simple expression of combinations (and/or) of Scintilla styles, and simple return value expressions. So "somebody" can do those one at a time and are largely separate from DLLs so its a good thing. I havn't examined if that simple expressions can cover all the filetype dependent functions in Geany though.
1. given that the number for all Lexilla is 4Mb IIUC, I'm no longer worried if all are included. Also IIUC there are no static constructors from Lexers so the linker will possibly even exclude unused Lexers. 2. The point of this issue is to allow full capability filetypes to be loaded into a _standard_ Geany. The current requirement is that a full capability filetype has to be compiled into Geany, so someone making a new filetype is making and distributing a special version of Geany, so users of the filetype have to get a distributed special version of Geany to use and test the new filetype instead of just a DLL file.
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.
For ctags, again, your approach is that it has to be compiled into Geany, making another version of Geany and the point of this issue is to not have to do that. A developer of a loadable filetype DLL is doing their own configuration for their ctags parser (and Lexer too) so its nothing to do with the Geany team.
Sure some of ctags is replaced by LSP, assuming the filetype has one of a suitable level. But its orthogonal to ctags and partly lexer.
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
Agree as much as possible should be config files, not code, but I __bet__ at some point something is complex enough to need code, eg me vs @b4n on auto-indentation :stuck_out_tongue_winking_eye:
There will always be a problem of the IDE implementation language being needed to add stuff, in Vscode its language specific plugins are Typescript (and that is needed to use the LSP IIUC, its LSP is not as general as Geanys LSP usage), or Eclipse needs Java etc. So studying C vs Typescript vs Java does not seem much different. We can always argue that Linux is C so its a really good reason to learn C :grin:
- at the end I'm afraid it will be just us ;-)
See Julia, that got a lexer and a parser and everything else with minimal Geany input except for having to merge it.
The same happens for Vscode and Eclipse, there are lots of pretty useless unfinished language specific plugins because somebody started and found it too complex.
IIRC @techee doesn't love it because it's unnecessay (code and memory overhead is low) and inefficient
Not sure I agree with @techee its much overhead for a DLL if only filetypes that are used are loaded.
I think you just disagree with Colomban's memory - I think I never said that ;-)
What I'd be more worried about is the compilation time where all the dlls will have to be linked separately and that could extend build time quite a lot.
In any case, performance isn't really the main concern of mine but the other things I mentioned before.
- The point of this issue is to allow full capability filetypes to be loaded into a standard Geany. The current requirement is that a full capability filetype has to be compiled into Geany, so someone making a new filetype is making and distributing a special version of Geany, so users of the filetype have to get a distributed special version of Geany to use and test the new filetype instead of just a DLL file.
But this is identical to any other feature and any other pull request - all these are "special versions" of Geany that (hopefully) get merged and become "official Geany". And I prefer the situation where pull requests are made and contributors are encouraged to merge their special versions upstream to the situation where there are many separate language support projects scattered across github and these don't get merged because the authors of these language DLLs don't bother to submit a pull request or these projects get abandoned and stop working for some reason.
For ctags, again, your approach is that it has to be compiled into Geany, making another version of Geany and the point of this issue is to not have to do that.
Well, I think this just tries to work around the real problem we have - too infrequent Geany releases. It would be nice to try to make a Geany release say twice a year, even if it contains just updated Scintilla and ctags. During the ctags update I try to check if there are new parsers for the languages we have and add those - compared to adding a completely new filetype this is much less work and I can do it without any problem.
See Julia, that got a lexer and a parser and everything else with minimal Geany input except for having to merge it.
Very nice when this happens but typically there are problems during the code review that have to be addressed. And it's better to have them addressed and the code merged into Geany than not addressed, have the code somewhere externally, and possibly abandoned in the future.
The same happens for Vscode and Eclipse, there are lots of pretty useless unfinished language specific plugins because somebody started and found it too complex.
This is exactly my worry - somebody gets excited about Geany and ThisCoolNewLanguage. He creates a separate repository with this language support. In the meantime, he switches from Geany to Eclipse and replaces ThisCoolNewLanguage with Java and abandons the project. If, instead, the only option to get the language to Geany is to create a pull request and get it merged upstream, even if he loses interest eventually, we'll have that language in Geany (which also means having it in Scintilla) and maintained.
I'm not a programmer (unless we count shell and python), but out of all the "text editor" bobs on a desktop Geany really hits some kind of sweet spot, except for adding languages.
Your discussion here made me think of the text editor Joe, which has now been retired to AUR for some reason. It's complete and anyone can add a language with a syntax file. Joe itself has a stateful lexer that when given the right information can parse anything and understand what it means.
Granted, it hasn't been sincerely updated in well over a decade, but it's feature complete and has a nice CTags system. Unfortunately, that also means it doesn't support LSPs, which do seem to be supperior for some things.
My 2-cents :) I have created several state graphs for languages under Joe, and while it took some getting used to, the system itself doesn't have to change with the changing landscape, just add another syntax.
My 2-cents :) I have created several state graphs for languages under Joe, and while it took some getting used to, the system itself doesn't have to change with the changing landscape, just add another syntax.
Note that Scintilla (the syntax-highlighting and editing component that Geany uses) is so much integrated into the editor (and plugins) that it would be really hard to replace it with something else and I don't think there are any plans to do that. So Geany will always depend on the availability of Scintilla lexers for language support.
That said, I don't think there's any urgent problem on Geany's side even with the current hard-coded language support. The fact that I added support for several languages recently was driven by my feeling that some language support requests have been neglected for a long time and I tried to fix that - and the currently open PRs are all I plan, there's nothing else in my sleeve. And I think it will be always the case that some "esoteric" languages (and of course what's esoteric depends on who you ask) will not be supported.
github-comments@lists.geany.org