[prev in list] [next in list] [prev in thread] [next in thread]
List: kwrite-devel
Subject: Re: KTextEditor Plugins
From: Emmanuel_Lepage-Vallée <elv1313 () gmail ! com>
Date: 2013-12-23 16:26:47
Message-ID: CAFnK6VXFU6nct4J=CdTgekB+Z04wqN_kPzRSbo309QM0w3AjeA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@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@milianw.de
> http://milianw.de
> _______________________________________________
> KWrite-Devel mailing list
> KWrite-Devel@kde.org
> https://mail.kde.org/mailman/listinfo/kwrite-devel
>
[Attachment #5 (text/html)]
<div dir="ltr">Hi,<div><br></div><div>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:</div> <div><br></div><div>* Use \
different colors to highlight parantheses (and [], <<, >> )depth <a \
href="http://quickgit.kde.org/?p=scratch%2Flepagevalleeemmanuel%2Fkte_highlight_parent \
heses_plugin.git">http://quickgit.kde.org/?p=scratch%2Flepagevalleeemmanuel%2Fkte_highlight_parentheses_plugin.git</a> \
(only highlight the current line to prevent slowness in incomplete code)<br> \
</div><div>* One is for changing the ctrl+ left / right word boundary for different \
languages</div><div>* One add a few Kactions things like add ")" and/or \
";" at the end on the line without moving the cursor</div> <div>* The last \
one is a Doxygen completion and validation engine I wrote for Umbrello a while back, \
it is in a branch somewhere.</div><div><br></div><div>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.</div> <div><br></div><div>Emmanuel</div></div><div \
class="gmail_extra"><br><br><div class="gmail_quote">On 23 December 2013 08:55, \
Milian Wolff <span dir="ltr"><<a href="mailto:mail@milianw.de" \
target="_blank">mail@milianw.de</a>></span> wrote:<br> <blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Monday 23 December \
2013 12:52:01 Dominik Haumann wrote:<br> > On Sunday 22 December 2013 22:34:50 \
Milian Wolff wrote:<br> > > On Saturday 21 December 2013 22:49:42 Christoph \
Cullmann wrote:<br> > > > Hi,<br>
> > ><br>
> > > during the last 10 years, close to zero usable plugins did show up \
for<br> > > > KTextEditor. The few existing that are useful, would be better \
merged<br> > > > into<br>
> > > the part, instead of having the whole code around to load plugins,<br>
> > > manage<br>
> > > them, ...<br>
> > ><br>
> > > For KF5, I would remove the KTextEditor plugin interface \
completely.<br> > > ><br>
> > > It was brought up, that this kills the possibility to have plugins<br>
> > > shared<br>
> > > between Kate / KDevelop.<br>
> ><br>
> > <snip><br>
> ><br>
> > I agree that sharing would be a cool thing to have eventually - but it<br>
> > should not be a priority.<br>
> ><br>
> > Rather, I'd argue along a different route on why you should keep - \
and<br> > > improve - the existing API, rather than ditching it.<br>
><br>
> And again, the KTE::Plugins were basically not use at all.<br>
><br>
> > A plugin API allows for much faster experimenting with new features,<br>
> > similar to what Sven mentioned. I don't need to create a \
"fork" of Kate<br> > > in a branch to try out a new feature e.g. New \
functionality can also<br> > > first be tested easily by interested people \
before then integrating it.<br> ><br>
> In this thread, we are talking a lot about keeping the KTE::Plugin<br>
> interfaces. But we are not talking at all about the use cases. Now we can<br>
> extend the KTE interfaces, but if they are again not used for the next<br>
> release cycle, it's completely wasted time...<br>
<br>
</div></div><snip><br>
<br>
Yes, you are right. Imo we should save us the time and discuss this properly<br>
during the sprint. I think we are more or less on the same page anyways ;-)<br>
<br>
Bye<br>
<div class="im HOEnZb">--<br>
Milian Wolff<br>
<a href="mailto:mail@milianw.de">mail@milianw.de</a><br>
<a href="http://milianw.de" target="_blank">http://milianw.de</a><br>
</div><div class="HOEnZb"><div \
class="h5">_______________________________________________<br> KWrite-Devel mailing \
list<br> <a href="mailto:KWrite-Devel@kde.org">KWrite-Devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kwrite-devel" \
target="_blank">https://mail.kde.org/mailman/listinfo/kwrite-devel</a><br> \
</div></div></blockquote></div><br></div>
_______________________________________________
KWrite-Devel mailing list
KWrite-Devel@kde.org
https://mail.kde.org/mailman/listinfo/kwrite-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic