How to make the CTags plugin default disabled for only KDevelop, but not Kate?

[René J. V. Bertin]

Friedrich W. H. Kossebau wrote:

> plugin, it has been ack'd by two KDevelop maintainers, one with explicit
> comment on the merge request itself to read for everyone.

I did not see a merge or other kind of review request. IRC is not the place for 
that kind of thing but if one was made on Phab I have to take back my remark, 
and wonder why I didn't get it.

> triggered here (+1 for that), then simply turned the back at the situation
> when review process was not straight-forward, letting all users run into this

I didn't create the bug which causes the duplicate menu items and as such only 
felt obliged to provide the solution I came up myself, which already took me 
long enough. I have been told several times not to ask (the devs) to solve my 
problems for me, so I don't exactly feel obliged myself to solve the devs' 
problems. The way new features have so often been received that I tried to 
contribute because I find them important have made me inclined not to insist and 
fight for them any longer. It is unfortunate that that affected a bugfix that I 
contributed proactively. At the time I thought that the review would see renewed 
activity or "bumps" when the bug started appearing in the wild, but it seems 
that activity went elsewhere. I am only on IRC if I have no other option.

> And while speaking out, it is also unfortunate that KDevelop contributors had
> not been subscribed to the review request https://phabricator.kde.org/D16779
> , which results in this automatic integration in KDevelop.

True, I could have, and I would have if I had discovered the duplicate menu 
issue earlier. Apparently that was after D16779 went in (because if not I would 
have submitted my bugfix first, and you would have known about D16779).

> before
> thought it would be just a hack by some people for themselves.

Yes, I remember that my bug fix was met with that kind of attitude and it didn't 
help making me more motivated to insist. 

> DUChain system. A proper solution would have been to write a language plugin
> which wraps around ctags and extends the DUChain design where needed
> possibly.

No, I don't think that's a proper solution because it duplicates functionality, 
is overly complicated and is based on a system that itself is so complicated 
that its maintainers have been failing to find a solution for certain recurrent 
problems.

> one uses the ctags plugin only, making them look broken. More, by the plugin
> injecting a "CTags" entry prominently visible in the main menu bar

I'm not certain where that comes from; I don't recall having done something to 
make it appear there (it certainly was never my intention; instead I was 
satisfied with it appearing in the Tools menu automatically, just like the menu 
from my 3rd-party zealsearch plugin).
 
> cheap hack, running against the design of KDevelop and screwing normal user
> experience.

It doesn't screw anything, but I'll admit that it causes KDevelop to screw its 
own context menu due to the duplicate items bug.

CTags may seem like a cheap hack to young devs who cannot imagine that we did 
without big IDEs that do almost everything they need except getting coffee (I 
wonder what they think of the built-in vi editing mode then ... would they miss 
and ed or emacs mode?).
People who have been at it a bit longer are likely to have ctags databases 
indexing all kinds of things that are not necessarily related directly to your 
project at hand (KDevelop currently cannot know about functions declared in 
header files that are not being included, for instance). So I see CTags as a 
potentially valuable complement to the duchain cardhouse, esp. for projects not 
based on CMake.
I'll give it to you though that CTags is cheap, compared to llvm+duchain in any 
case (the version I have installed is over 200kb, which I don't find "cheap" for 
a traditional CLI app written in C.)

R.