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


<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br>Reply to this email directly or <a href="https://github.com/geany/geany/pull/862#issuecomment-170742045">view it on GitHub</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/ABDrJ7k429O53ex0w_NVabJR0Dm-ZwEZks5pZEAKgaJpZM4HB6zU.gif" width="1" /></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
  <link itemprop="url" href="https://github.com/geany/geany/pull/862#issuecomment-170742045"></link>
  <meta itemprop="name" content="View Pull Request"></meta>
</div>
<meta itemprop="description" content="View this Pull Request on GitHub"></meta>
</div>