[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwrite-devel
Subject:    Re: KTextEditor Plugins
From:       Michal Humpula <michal.humpula () seznam ! cz>
Date:       2013-12-23 16:43:05
Message-ID: 3259365.61TWYXMsGv () amonsul
[Download RAW message or body]

Hi Emanuel,

would you be please so kind to share the "Yakuake like console" plugin? IMHO  
that could be nice addition for the Kate5.

Cheers
Michal

On Monday 23 of December 2013 11:26:47 Emmanuel Lepage-Vallée wrote:
> 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_pa
> rentheses_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

_______________________________________________
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]