Issue with KDevelop: Is it using different parsers in parallell for different puropuses?

[Kuba Ober]

> > KDevelop 4 won't have a new editor.  It is using the KTextEditor
> > interfaces. Those interfaces allow KDevelop 4 to choose to do its own
> > highlighting.  The only way this could be re-used for KWrite is for the
> > default KTextEditor implementation -- katepart -- to use kdevelop-pg
> > parsers for its highlighting.  Who knows, perhaps the Kate devels will
> > eventually do this, but the place to talk about that is on kwrite-devel
> > as you yourself noted.
>
> True. Well... since obviously the decision is made, I guess I'll wait
> and see. I still think it would be good if KATE's highlighting was more
> language aware. It will be unfortunate if KATE winds up implementing a
> different language-aware parsing engine that competes with KDevelop's.

Kate already has it. It's implemented and I don't see it being reworked any 
time soon, unless a volunteer steps up to the plate. Calling it a parsing 
engine is buzzowordiness to me. It's a simple state machine coupled to a 
pattern matcher. Simplicity is the key word here.

It works pretty well considered how simple it is. It *is* langauge aware. Have 
you seen how many languages Kate's highlighter supports? All of those 
highlight fine in KDevelop as well. I have projects where the test harness 
has quite a bit of Octave and Common Lisp code in them, and Kdevelop (via 
KatePart (?)) hightlights those sources just fine. Have you actually tried 
what you're talking about?

The only thing, I gather, that KDevelop may potentially do is override the 
highlighting for files it knows how to highlight better than what Kate does. 
That more powerful highlighting functionality could be potentially put into a 
separate framework and made useable by Kate (and other applications), but 
again -- someone has to design it and code it first. I suggest you give it a 
try if you place such a high value on that feature (as you claim).

Cheers, Kuba