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

[Friedrich W. H. Kossebau]

Hi René,

Am Samstag, 13. Juli 2019, 15:51:08 CEST schrieb René J.V. Bertin:
> don't you think you overstepped a bit here disabling the plugin by default
> for everyone while you are apparently the only one to be bothered by its
> presence, and there exists a simple hack to disable it via the environment?

While I am the one who did the related patch to make it no longer a default 
plugin, it has been ack'd by two KDevelop maintainers, one with explicit 
comment on the merge request itself to read for everyone. As well as no-one 
raised concerns against it when this was mentioned on the #kdevelop irc 
channel. So I am at least the one bothered enough to take action as first and 
also having time available to do so, but not the only one bothered. And not 
bothered about its presence, but being a default for everyone.

Next, in the recent weeks there have been a few people appearing on the 
#kdevelop irc channel asking about how to get rid of the duplicated context 
menu entries now appearing. Which are triggered in released versions now, 
because there the ctags plugin since release of Kate 19.04 automatically 
enters KDevelop by default, and which triggers that bug if enabled.
So breaking KDevelop for everyone after a bit due to context menu being 
unusable. Only escape known currently: disable ctags plugin.
No-one was heard to cry out that this makes them losing the ctags plugin.

((
Then, I am also disappointed that the person responsible for this situation 
with the duplicated context menu entries being triggered and knowing about 
it, while initially having properly cared trying to write patches for the bug 
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 
mess in released versions while the person was happily using their patched 
software (-lots for that). Just mentioning this here for more context, this 
is orthogonal for the actual question whether this feature should be enabled 
by default. Though it touches the area of "maintained plugin" which also is 
important when it comes to defaults.
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. Myself only 
learned about this patch being upstreamed when wondering why people using 
normal releases now see the duplicated context menu entries bug, before 
thought it would be just a hack by some people for themselves. Including all 
stakeholders is something to improve the next time.
))

> I'll remind you that a (small) number of users have complained about lack 
of
> parser support for languages not related to C/C++, which is exactly the
> sort of situation for which I make CTags plugin work in KDevelop.

Which IMHO is a hack. KDevelop and all its plugins are built around the 
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.

The ctags plugin as it is now is a completely separate system, which is 
confusing for users, as this is no-where indicated in the UI (besides not 
documented in docs, though that is something other parts in KDevelop suffer 
as well sadly, still, not good and another minus point).
All other tools expect any data about the edited code to be in the DUChain 
system. There is no UI indication why they would not show or have data when 
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, it sends 
to wrong signal to any newcomers, that KDevelop is just using ctags.

Personally I am happy to enable people to use this hack, as a temporary 
solution for cases where they want to use KDevelop and no matching language 
plugin exists or the current DUChain system is over-strained, and where 
people can stand the hack, know about it and the resulting non-integrated 
other KDevelop language features.
But no-where do i think it should be recommended to all normal users. It's a 
cheap hack, running against the design of KDevelop and screwing normal user 
experience.

Cheers
Friedrich