kossebau added a comment.
In D16882#359888 <https://phabricator.kde.org/D16882#359888>, @rjvbb wrote: > > _If_ it is found that the root bug is in KTextEditor, sure. <snip> > See https://bugs.kde.org/show_bug.cgi?id=401069#c2 That looks like good work onto finding the culprit code, Please concentrate the related discussion there. > I don't want to delve any deeper than that into code that isn't mine and I'm not planning to work otherwise. This goes beyond using the CTags plugin in KDevelop (which is someone else's idea) and as far as that use is relevant to me I'm perfectly happy with a workaround (here or in KTextEditor). Please check what you wrote here. To me it tells that you are in the wrong place. KDevelop, KTextEditor & Co are not for mainly having fun tinkering with code of an IDE, but to create a usable product, which can be easily maintained in snippets of free time and which is independent from one single company's interest. Dumping hacked-together-until-it-works solutions one does not plan to work on further right from the start or really care for would be quickly the death of this. Please tell, are you not serious about using the CTags plugin and maintaining the integration? I need to know why I should spent my time on reviewing this patch and the related issues. >> I can only urge you to invest into learning how to do debugging the stuff that you work on. It's basic developer tooling. > > Oh, I'm pretty confident I've logged more hours in more different debuggers than you, more than enough to know my strengths and weaknesses. Well, I just picked up your "I suck at debugging event-driven code". If that is your weakness, exercise on it to improve it. It's a required skill here, given that lots of stuff is event-driven in kdevelop. I do not make assumptions about what you have done and what not (and I also resist, almost, to hint to quantity vs, quality ;) ). >> > And here the API seems to be the emission of the KTextEditor::View::contextMenuAboutToShow signal, that one should only be done once and for the given view where the menu is shown on: "Signal which is emitted immediately prior to showing the current context menu". > > That doesn't say explicitly that there will only be 1 such signal for the active view so this aspect could even be platform dependent. Would you agree that it is surprising to have more than 1 signal per case? So would we agree that this is implicitly given? What do you mean by platform dependent? >> generation.s, but seeing myself still part of the near future kdevelop generation, here my banner script: "Stop creating code to work around bug symptoms ." > > Another banner would "nobody is paid to fix someone else's bugs" (except for a few poor sods whom I hope get paid really well for it). This bug became now also your bug as it is inhibiting your desire to enable the ctags plugin. Bad luck, but also normal developer life. Your work-around would become also my work-around as kdevelop co-contributor, and I do not like work-arounds when they are toll code for being lazy now. Even more if it is someone else being lazy. REPOSITORY R32 KDevelop REVISION DETAIL https://phabricator.kde.org/D16882 To: rjvbb, #kdevelop, kossebau Cc: kossebau, kde-frameworks-devel, kdevelop-devel, glebaccon, antismap, iodelay, vbspam, geetamc, Pilzschaf, akshaydeo, surgenight, arrowd
