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.