How to make the CTags plugin default disabled for only KDevelop, but not Kate?
Friedrich W. H. Kossebau
kossebau at kde.org
Sun Jul 14 11:52:06 BST 2019
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
> 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
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
More information about the KWrite-Devel