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.

Ok, so lets muddle along in our current way? I don't understand what you have against having nominated supporters of languages? Does the world fall down if we have someone to ping when an issue about filetype X is raised? Otherwise if its not in the mapping all we can do is tell the user to raise it upstream because we don't know if they have the language wrong or not. Improving support doesn't seem to me to be a negative, especially if more languages are going to get added as below. We might not get volunteers for all languages, but at least its possible support will improve for those that have backers.

support for some language is loadable from some external source but I think it's an overkill.

Yes, thats exactly what I mean. If the dll is only loaded when the filetype is first used (ie its not linked in) it doesn't slow startup. Its not loaded until a file of that type is opened. And then all those parts of Geany that have built-in decisions based on filetype can be exported to the dll instead of being forgotten to be updated when languages are added. And also all those assumptions based on "all languages are C" can instead be provided by the dlls. That is why Vscode and almost all other IDE/editors do it that way.

For normal parsers we can be pretty sure that parsing happens more or less in linear time but not here.

It happens in that way because most parsers are able to skip statements and expressions and only parse declarations, and for most languages only global declarations are parsed. Only the recentish C/C++ parser does locals AFAIK. As was discussed on universal-ctags/ctags#4053 Kotlin needs to parse statements and expressions because it can have declarations in them. So its going to be slower because of the language, however the parser is implemented.

Lexilla is C++, and its been my experience that nearly all of a C++ codebase gets paged into the working set because of constructors being spread through the code and being called when global objects are being created, objects like lexers. I havn't specifically evaluated Lexilla, but I don't see why it would be any different in general. C parsers might be less paged as you argue, but it will depend on the order its loaded into libgeany.so.

But as I said, when actual numbers for size were provided for Lexilla, even if all the 4Mb is loaded, its pretty immaterial.

There needs to be numbers provided for the parsers, you claim the Kotlin one is "slow", but no numbers are forthcoming. Evidence is the way to persuade me, how big is the code memory for libctags, if its like Lexilla and its small (including Kotlin and TOML) I don't care, but need numbers. And how "slow" is the Kotlin one.

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

That makes you sound very contradictory, on one hand you are saying "lets have more languages" but on the other hand "not languages that have specific characteristics" because they might in theory be slow and you can't analyse the code.

Also you claim that additional parsers have little effect on the working set and add little overhead for those that don't use it. Therefore, if you don't use it, what do you care if its slow, or if there is some characteristic that you can't glean from the source.

If we are accepting all languages that are PRed as you propose, the Kotlinists are the ones that need to make the judgement, not you, or me, or @b4n. A user of the Kotlin parser has said it is acceptable in practice #3034 (comment) (oh, and that provides one of my numbers, 150k, thats not terrible, so I am now happy about it) so why are you worrying?

Either your claim that adding languages doesn't cost non-users is wrong or you should not care about theoretical costs that only Kotlin users pay. If the slowness becomes an issue then take the Geany approach, add an option 😁 to allow built-in parsers to be disabled so Kotlin users can still edit their code, at least until the Kotlin LSP is improved and parsing moves asynchronous.

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