On 12 January 2016 at 09:59, Jiří Techet notifications@github.com wrote:
That is likely to make autocompletion worse than it is now.
How? This definitely didn't work before. What about trying it first?
Things in namespaces autocomplete now (I turned it on to check :).
Everything in C++ is namespaced (or should be) so what you are saying is that no name in a namespace will provide an autocompletion.
It doesn't work for namespaces themselves only but works for the stuff inside - have a look at Colomban's example - you get scope completion for the contents of the classes inside.
Yes, Colombans example makes it clear that its has gone backward since namespaces work now.
C++ autocompletion is such rubbish that I now turn it off. Python autoc is such an annoyance I turn it off. Basically I turn just it off completely. And decisions to arbitrarily not support large parts of a languages features doesn't help.
I can only say - patches are welcome. I'm not saying it's perfect but it's much better than before (which was really broken in some cases) and can always be improved. I don't want to put more and more patches on top of this (as you suggested yourself yesterday) because then it never gets merged.
Sure, but saying "I have created a regression by ignoring namespaces but I will fix that in another PR very soon" is very different to saying you have created a regression and won't fix it.
Thank you for putting the effort into it, but instead of using your effort trying to solve a broken system it would be a better spent to provide the hooks so plugins can control these things, with libclang being to obvious contender for C++.
This is something I'm not interested in - if you want to make clang work then clang will have to have full knowledge of the build process which means Geany will have to start managing your project. And this is not something I want Geany to evlove into - I want Geany to be build system independent and cross-language. If I wanted something like this, I'd just grab some full-blown IDE - I feel zero motivation to recreate something like that. And making such a thing work is A LOT more effort than the few hundreds lines in this patch.
Indeed, but the more effort that goes into the bullt-in system the harder it becomes to allow plugins to replace it. Matthew had a look at libclang, but found that it was not possible to inject the information libclang produces into Geany IIRC. If a plugin wants to be a "full blown" IDE it should be allowed to be (but I won't be doing it any time soon).
I definitely wouldn't call the ctags parsing stuff "broken" - actually think the ctags parsing works wonderfully well (and is super-fast). It just depends what expectations you have - it won't be able to do some things like things that require function body parsing.
If it gives lots of wrong options and misses lots of right options its broken. It may be broken due to limitations imposed for good reason (as you say above) but its still broken.
To be honest, I also don't care much about the autocompletion but the goto tag definition/declaration feature is fantastic (and getting #406 https://github.com/geany/geany/pull/406 merged would make a much bigger practical difference for me than these patches).
That indeed looks like a good idea, pinged it for you :)
The main benefit of these patches is mainly the TM cleanup - the patches merged a year ago concentrated mostly on tag sorting and management, these patches clean up searching. Some of the previous code was *really* bad and hard to read and I think this will make TM much easier to maintain. The scope completion improvements are more or less a side-effect of this. There is some more TM-related work I'd like to do (Colomban, don't worry, should be more or less formal cleanups and not such headache-makers like this :-) but I think the code is pretty understandable now.
That is a good reason to make the changes, but it didn't really come across that way. But again, code cleanup at the cost of regressions isn't good.
— Reply to this email directly or view it on GitHub https://github.com/geany/geany/pull/862#issuecomment-170737058.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/862#issuecomment-170742045