Geany devs can create any filetype, but supporting it well is different. There have been some atrocious highlighting mappings when the person who made them didn't understand the language, similarly there have been some poor categorisation of symbols (usually to C categories, not all languages are C you know ;-), and then there are all the functions hidden away that decide things based on the filetype. Of course Geany devs can create a filetype for any language, but my point is we should have someone who knows the language to provide an input to it rather than treat them all as C.

Yes, but things can be fixed over time. If we make some mistake, someone knowing the language will point it out or will create a pull request and it gets fixed in the next release - pretty typical open source development. So by the means of bug reports and pull requests, we actually have people knowing the language.

My suggestion was that each filetype has a dll, sure the biggest part of them is the lexer and the parser, but also all the various functions hidden around Geany that depend on filetype can either be in config file, or in the dll.

Well, we can organize our sources whichever way we want and it can still be single libgeany.so like now so it's not really an argument for many shared libraries. The only valid argument I see is if we want to do something like vscode where e.g. support for some language is loadable from some external source but I think it's an overkill.

But reviewing and debugging should be happening in uctags, not in the import to Geany? If its reviewed and benchmarked there (size and speed) then many client projects will benefit.

I tried it a few years back and it was just too slow to my taste (barely usable on Raspberry Pi with 400 LOC file). And uctags doesn't have the same "real time" performance requirements like Geany so the fact that it works for ctags doesn't necessarily mean it's suitable for Geany. Also, I can't imagine anyone is able to review the generated code - I'm most worried about about some pathologic case that you don't hit normally but only for some language construct where certain grammar rules cause much slower parsing - we can't try all the possible input to be sure there's nothing like that and we can't inspect the code because it's too big and unreadable. For normal parsers we can be pretty sure that parsing happens more or less in linear time but not here.

To be clear, I'm not saying we cannot merge it - it's just a completely different kind of parser than we have with some drawbacks and someone with a higher karma level than me (@b4n) should decide if we want such parsers or not.

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