Impending removal of Smart* code from katepart

[Hamish Rodda]

Hi,

On Sun, 11 Apr 2010 11:08:07 pm Christoph Cullmann wrote:
> For KDE 4.5, smart stuff will stay there, like it is. I will only remove
> not used methodes, to avoid further spreading.
> 
> But maybe for 4.6 or later, there will be a replacement for the whole
> smart stuff.
> Which is only a subset of the features it has now.
> 
> Atm, what is missing for kate part internally to remove the usage of
> smart is the missing ability to add attributes to the new
> Kate::TextRange's and efficient lookup.
> I hope to fix that already for KDE 4.5.
> 
> And then, in the future, smart* will be purged from katepart.
> 
> I won't let this be discussed.
> 
> Hamish and David can fix as many corner cases as they want, but given
> that stuff is not understandable by anybody beside Hamish (and the fact
> it has that many bugs shows not even by him), it will vanish.
> 
> Smart* is the major design error of katepart.
> It will be purged.
> 
> I will for sure keep kdevelop in mind while designing the replacement.
> But it won't be thread safe, there will be no mutex in kate part.
> KDevelop needs to lock itself.

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.

Do you have any design in mind for the "ability to add attributes to the new
Kate::TextRange's and efficient lookup." ?

Thanks,
Hamish.