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.

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