KTextEditor Plugins

[Emmanuel Lepage-Vallée]

Hi,

Just my own 2 cents before the thread end (I won't go to your sprint, so,
for me, it is now or never). I would like to point out that I have 3 (or 4,
depending on how you count) Kte plugins of my own. So there is definitely
more than 0 out there :P. Of these 4, only one is in good enough shape
and/or relevant enough to be used by other users:

* Use different colors to highlight parantheses (and [], <<, >> )depth
http://quickgit.kde.org/?p=scratch%2Flepagevalleeemmanuel%2Fkte_highlight_parentheses_plugin.git(only
highlight the current line to prevent slowness in incomplete code)
* One is for changing the ctrl+ left / right word boundary for different
languages
* One add a few Kactions things like add ")" and/or ";" at the end on the
line without moving the cursor
* The last one is a Doxygen completion and validation engine I wrote for
Umbrello a while back, it is in a branch somewhere.

I do use those KTe plugins across multiple apps, so at least, there is one
person that does that. While some of these plugins could probably be
implemented in JS or Python, mine are in C++. I really like the concept and
I usually don't want a full IDE or 50 million dockers around (I also have a
Kate plugin that turn the dockers into Yakuake like console so I don't
always see them). Please don't remove "atomic" C++ plugins. I guess there
is not many users like me, but there is probably more than just me. In the
Sublime world (many of my coworkers use it) or Vi world, having its own
extensions is quite common. A quick search on Github show that there is
indeed some. I don't mind if you break the API, it is currently far from
perfect (too many useful features are in the private APIs, like supported
language list), but please don't remove it entirely.

Emmanuel


On 23 December 2013 08:55, Milian Wolff <mail at milianw.de> wrote:

> On Monday 23 December 2013 12:52:01 Dominik Haumann wrote:
> > On Sunday 22 December 2013 22:34:50 Milian Wolff wrote:
> > > On Saturday 21 December 2013 22:49:42 Christoph Cullmann wrote:
> > > > Hi,
> > > >
> > > > during the last 10 years, close to zero usable plugins did show up
> for
> > > > KTextEditor. The few existing that are useful, would be better merged
> > > > into
> > > > the part, instead of having the whole code around to load plugins,
> > > > manage
> > > > them, ...
> > > >
> > > > For KF5, I would remove the KTextEditor plugin interface completely.
> > > >
> > > > It was brought up, that this kills the possibility to have plugins
> > > > shared
> > > > between Kate / KDevelop.
> > >
> > > <snip>
> > >
> > > I agree that sharing would be a cool thing to have eventually - but it
> > > should not be a priority.
> > >
> > > Rather, I'd argue along a different route on why you should keep - and
> > > improve - the existing API, rather than ditching it.
> >
> > And again, the KTE::Plugins were basically not use at all.
> >
> > > A plugin API allows for much faster experimenting with new features,
> > > similar to what Sven mentioned. I don't need to create a "fork" of Kate
> > > in a branch to try out a new feature e.g. New functionality can also
> > > first be tested easily by interested people before then integrating it.
> >
> > In this thread, we are talking a lot about keeping the KTE::Plugin
> > interfaces. But we are not talking at all about the use cases. Now we can
> > extend the KTE interfaces, but if they are again not used for the next
> > release cycle, it's completely wasted time...
>
> <snip>
>
> Yes, you are right. Imo we should save us the time and discuss this
> properly
> during the sprint. I think we are more or less on the same page anyways ;-)
>
> Bye
> --
> Milian Wolff
> mail at milianw.de
> http://milianw.de
> _______________________________________________
> KWrite-Devel mailing list
> KWrite-Devel at kde.org
> https://mail.kde.org/mailman/listinfo/kwrite-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20131223/c96a4bc1/attachment.html>