Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
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?
OMG, this is getting absurd. Don't you see the reality? Geany is a really niche editor which man-power-wise cannot compare to vscode or even vim. If you have a look at the activity, most Geany developers don't have time for the project. Would I like to have an expert for every language? Sure, bring them here! I'm all for it! I'm sure Neil would love to have an expert for every lexer too and Masatake in uctags as well.
But until you assemble a board of experts, I'll keep living in reality and try to improve language support in Geany despite my limited knowledge of all the languages (and in fact, learning a bit about new languages is one of the things that make developing an editor fun).
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.
It just doesn't happen - if I'm not mistaken, SciTE uses full lexilla and it starts really fast (@nyamatongwe am I right?). I'd suggest to spend our time on real problems and not inventing non-existing ones.
That is why Vscode and almost all other IDE/editors do it that way.
Yes, but these are giant plugins here that possibly contain whole compilers, language servers, etc. with 100MB sizes or more. They tend to do crazy things in the background and I'm really happy nothing like that is in Geany - you don't really want to have all these built in. But with Lexilla it's just a few "simple" lexers whose code won't get normally executed.
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.
Skipping statements speeds up parsing but doesn't change the complexity of the algorithm - it's pretty much linear. The new C++ ctags parser that parses function bodies in a limited way is say twice as slow as the original one (in fact a bit faster) but the Kotlin parser is 100x slower which I assume is because of backtracking. With PEGs you have unlimited lookahead which can cause exponential complexity in the worst case because of backtracking and at least I am not able to say whether this "worst case" happens in the 20000 line code base and what effect it will have on performance.
There needs to be numbers provided for the parsers, you claim the Kotlin one is "slow", but no numbers are forthcoming.
You have numbers in #3034 in which you were involved so you should know the facts - the PEG parser is in the order of magnitude 100x slower than normal parsers.
Evidence is the way to persuade me, how big is the code memory for libctags
I'm not sure all ctags parsers should be made part of Geany - it's something you started suggesting. I don't think normal users will know how to do the mappings and there are quite a few specific settings that they probably won't get right - this is more about tag manager knowledge than language knowledge so we are better people for it. But ctags parsing is a bonus feature - the basic one is syntax highlighting and general filetype specification. When that is present, one can start using a LSP server if there's one and in such a case ctags isn't needed at all.
In fact, I'm not even remotely planning anything like rewriting Geany configuration and including all the lexers. I mentioned it as a reaction to this post of yours
What would be better than keeping adding built in stuff would be a @techee minor 100000000 or so line change that allows lexillas and ctags parsers and the language configuration to be in plugins so the cost of low traction languages isn't imposed on everybody (or dlls with different API if appropriate, eg IIUC Lexilla allows for that) ... now thats something for you to get your teeth into
where you claim something about "cost of low traction languages isn't imposed on everybody" which you failed to prove so far. If you don't believe me or Neil, you (not me) should come with numbers and prove such a problem exists. Nobody has reported such a problem, I haven't seen such a problem neither on my development machine nor Raspberry PI and when you want someone to develop such a feature, you should come with convincing arguments for it.
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.
Please just read what I say. I'm not saying " languages that have specific characteristics" but "PARSERS that have specific characteristics" - it's not about Kotlin, it's about PEG parsers in general, see above.
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.
Because even though I personally don't use Kotlin, it should be usable for other users even on slower hardware. If Geany blocks for 1s every time I write a letter in a 400 LOC file on a Raspberry Pi, it's just unacceptably slow for me at least. Others may have a different opinion and feel free to overvote me.
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?
I'm not saying we should accept just anything anyone ever proposes (@elextr please stop putting words into my mouth that I don't say, I really don't like that) - like every PR, language support PRs undergo a review and if they don't meet certain criteria, they aren't merged. For me, here, the performance criterium isn't met so I personally won't merge it and I feel obliged to point out the possible problems and not to be silent about them. If you, Colomban or Enrico have a different opinion, and want to merge it, I'm completely fine with it.
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.
Wow, what a garbage argument this is! How does it become either the first or the second?
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
Alright, this is actually the only useful input in the discussion (which I'm ending on my side because the above is not leading anywhere, is hugely off-topic and has nothing to do with what I plan to do). We already have such a settings - it's
[settings]
tag_parser=and when left empty, it already disables the builtin parser. So in case the Kotlin parser gets merged (which I think really requires Colomban's approval), this could be left empty by defalut with a comment that the parser is slow but that it can be enabled by removing this line.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.