KDE/kdelibs/kate/buffer

[Christoph Cullmann]

Niko Sams wrote:
> On Sat, Apr 10, 2010 at 10:39, Christoph Cullmann <cullmann at absint.de> wrote:
>   
>> Perhaps (for the future), you should take a look how qtcreator does the
>> parsing, after the last talks to Roberto, it seems that more intelligent
>> it might be good idea to fork that parser or at least steal some (LGPL)
>> ideas.
>>     
> Forget that, that's not an option.
>
> However what imho could be done is porting KDevelop to the new Buffer and Cursor
> stuff. (But I have no idea what needs to be changed to do that)
> I think we should:
> - as a short term goal make kate and kdevelop as stable as possible
> with the current technology
> - as a mid term goal work out a plan what could be changed in which way
> - as a long term goal have all all non-optimal code replaced by something better
>
> Unfortunately we are currently we are stuck at step 1, because david
> and hamish (the only
> ones who have in depth knowledge about what kdevelop does and needs) are short
> of time.
>
> I think we can solve this issue together! No need to kill each other :D
>   
I like the idea of cooperation, but the current situation is not acceptable:

Nobody can do changes perfectly correct in kate part without breaking
kdevelop and then getting constant complaints from either the kdevelop
devs or users...
To be honest, I don't like that.
I designed the new buffer in a time-frame of some weeks, it got unit
tests from the start, it handles encodings lot better and it is faster...
But what do I get: complaints and insults
I asked for input on kdevelop list, nothing, and now the whining is great...

I have not reverted milian's commit, but I won't tolerate any more
invasive stuff.

If kdevelop gets crashs => lock your smart mutex in more places.
Don't patch KatePart to hide your faults...
The smart mutex will stay there, at least for KDE 4.5

What would help me a lot:
Could I get a list of the interface functions KDevelop uses of the smart
range interface?
I would then deprecate any other and kill the implementation, that the
Smart* mess at least not spreads further.

Btw., if nobody steps up to provide a list, I can do my own, by grep -r
for each interface function.
Each I don't find will get a deprecated marker and it's implementation
will do kFatal.

Greetings
Christoph

-- 
-------------------------------------- Christoph Cullmann ---------
AbsInt Angewandte Informatik GmbH      Email: cullmann at AbsInt.com
Science Park 1                         Tel:   +49-681-38360-22
66123 Saarbrücken                      Fax:   +49-681-38360-20
GERMANY                                WWW:   http://www.AbsInt.com
--------------------------------------------------------------------
Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234