OMG, this is getting absurd. Don't you see the reality?

Statements like this are unneccessary and do not contribute to useful discussion. There should be no reason that suggestions for improvements cannot be made, be they to processes or code or the whole application. Until it is actually tried we don't know how "impossible" something is. For example in the past everybody was exorcising demons 👿 every time LSP was mentioned, but in the end it cost a few hundred lines in Geany because all the complexity was external, but nobody knew that until you actually implemented it. It is inappropriate to try to shut down suggestions for alternative program organisations or processes until someone implements it.

For the filetype support, all it takes is a list of contributors who are willing and able to comment on filetype issues so they can be pinged when appropriate, eg C - @b4n, C++ - @elextr, Go - @techee, Kotlin - @dolik-rce?, Python - @eht16, if nobody is willing to look at topics relating to a filetype then its users get whatever is made for them, or someone steps up to help. But at the moment there is no way of someone doing that.

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.

Possibly you have the misunderstood the reason behind the suggestion. It is nothing to do with Lexilla specifically, it is to do with combining all code for a filetype in one place (which may include Lexilla lexer and uctags parser) so it can be found and checked and modified easily. The point is to make it easy to add flexibility for language specific features that are currently coded into Geany and spread throughout the code. And it is easier to add features that should be language specific but nobody has done it because its too much bother finding all the places to code it into Geany. Geany itself should provide filetype independent fallbacks, not try to handle per filetype specifics spread throughout.

I have been calling it a DLL because it might need a different API, but this could be a standard Geany plugin, but the current plugin API does not really support plugins providing functionality back to Geany, thats why LSP has to have specific tests where it hooks in. But I suppose that mechanism could be extended to per filetype functions as well.

Yes this is a re-organisation of Geanys structure. Why is it impossible to suggest such a thing? If it is not mentioned it will not happen, ever.

[end gripe]

Now to specifics.

but the Kotlin parser is 100x slower which I assume is because of backtracking

The problem with PEG is the potential infinite lookahead as you said, and yes that can cause exponential performance, but the point of packrat is to use memoization to linearise performance. So your assumption should not be true. That does not mean that the packcc implementation is fast of course, it could be slow linear performance or the implementation of memoization could be simply wrong. I agree that its not likely that a human can assess that from the packcc output code.

the PEG parser is in the order of magnitude 100x slower than normal parsers.

None of those parsers are parsing the same code and giving the same result, its totally inappropriate to compare them like that. Also so what? The Kotlin user has stated that the performance is acceptable in practice even though you are unhappy at performance of a single example Kotlin code on a Rpi. Are you really saying that nobody can have Kotlin symbols because it might not be fast enough on a slow machine with a specific example?

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.

As I pointed out above packrat PEG parsers do not in general have any characteristics that should make them unacceptable. And I am saying it depends on the language, because if a language allows declarations anywhere, then it requires all of its code to be parsed to locate the declarations. For languages that allow declarations to be made inside statements and expressions they will naturally be slower to parse than languages where it is easy to decide declaration vs statement vs expression and skip parsing the latter two.

I'm not sure all ctags parsers should be made part of Geany - it's something you started suggesting.

I did not intend to suggest that, and I don't believe I suggested that, I only suggested all of Lexilla which, as you noted, has precedent in other applications. And I didn't say all lexed languages need to be a filetype, it could just be dead code (gasp!!! horror!!!). And in fact if a lexer is not referred to from Geany I suspect a smart enough linker will omit it anyway. And the same for ctags parsers if we ever moved to simply linking all of them. This is suggested to simplify the process of importing Lexilla and Uctags.

For the specific Kotlin parser, size was hidden in a previous comment and when I found it I pointed out it was small enough to stop me worrying, so its only the possible performance that is an issue.

Benchmarking a variety of Kotlin code and plotting speed vs size would be useful guidance since the packcc output is not amenable to analysis, that will show linearity or not, what the coefficient is, and if there is a constant or not.

But ctags parsing is a bonus feature

True, but if there is a parser available there should be no reason not to add it to a built-in filetype if "somebody" makes a PR.

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)

I apologise if I misunderstood, but that was what I thought you meant. But the point was the rest of the paragraph that the trade off of feature vs performance is something that users need to make. And my suggestion that making it possible for configuration to remove built-in parsers mitigates performance issues if users find them in real life meaning, we don't have to worry so much.

And I presume you apologise for the misrepresentations you have made due to your misunderstandings of my arguments in the next part of the post.

We already have such a setting

I didn't think tagparser= worked on built-in parsers because they were hard coded, (Edit: actually now you mention it, I have a vague memory that was added in the LSP merge), if it does then great, now if any language is too slow on a users platform (eg your Rpi) they can disable it.

That means there is even less argument that we need to police parser performance if it works acceptably for some users.

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