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

List:       kwrite-devel
Subject:    Re: Impending removal of Smart* code from katepart
From:       Milian Wolff <mail () milianw ! de>
Date:       2010-04-12 9:07:45
Message-ID: 201004121107.49573.mail () milianw ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Christoph Cullmann, 12.04.2010:
> On Monday 12 April 2010 08:42:31 Hamish Rodda wrote:
> > I completely understand your point of view.  I regret that I have not
> > been able to remain active in kate.
> > 
> > May I propose a solution that should work for everyone.
> > 
> > The smart interface is, in my opinion, a fairly self-contained piece of
> > code which could be separated from kate part with only a minimal
> > interface into and out of kate.
> > 
> > The hooks out of kate that are required are simple - 100% accurate
> > signals of exactly where the buffer has changed.  They already exist but
> > are not exposed, from what I can remember.  However, for this plan to
> > work, they must remain absolutely flawless.  This was the source of many
> > of the early Smart* bugs.
> > 
> > The major hook back into kate is at rendering time, to get the extra
> > attributes to draw.  I presume you already plan to provide an alternative
> > to this, as you allude to above with talk of a replacement.  We can adapt
> > the Smart* code pretty easily to whatever interface you wish for this.
> > 
> > We would then move the Smart* code either into a separate library/plugin
> > should others still want to use it, or into kdevelop itself.
> > 
> > As you say, kate can then go back to happy thread unsafe existence, the
> > Smart* code would not be loaded when running kateapp.
> > 
> > Then you can send any bug reports about Smart* to me, kdevelop, or
> > /dev/null, as you prefer.
> > 
> > The only big loss to the functionality available with the smart interface
> > will be to dynamic attributes, because they rely on receiving information
> > about mouse position in the view, and cursor position.  This is an area
> > of the smart interface that never really reached its true potential,
> > sadly. However, the cursor position is already provided; mouse position
> > translated to text cursor could also be exposed easily, allowing me to
> > resurrect even this functionality if we still want it.
> > 
> > If we're going to go ahead with this, I propose we do it now, for KDE
> > 4.5. We're going to end up with two different sets of bugs anyway as
> > kdevelop is going to release against the current code (unless there is a
> > change of heart with this development within the kdevelop devs), so we
> > should mimimise the time that the old code is around for.
> 
> You can do so and move the code to kdevelop, as internal interface, the new
> TextBuffer provides signals for changes which work.
> Still the interface for the ranges with attributes is not done for the
> replacement, see below for the current plan for fast lookup.
> 
> > Do you have any design in mind for the "ability to add attributes to the
> > new Kate::TextRange's and efficient lookup." ?
> 
> The text blocks will have set of ranges affecting it, if a range spans
> multiple blocks, which is unlikely, beside for selection, it will be added
> to all blocks spanned.
> This way you ever only need to lookup the ranges for the block, given the
> block is small per default (256 lines), this should be fast.

Can you please point me to the new API for custom highlighting, or is that not 
yet written?

Thanks
-- 
Milian Wolff
mail@milianw.de
http://milianw.de

["signature.asc" (application/pgp-signature)]

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