How to make the CTags plugin default disabled for only KDevelop, but not Kate?
René J. V. Bertin
rjvbertin at gmail.com
Mon Jul 15 14:09:44 BST 2019
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).
> 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
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
> 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
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.)
More information about the KWrite-Devel