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.

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.
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 😜

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 😁

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.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.