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

Adam Treat treat at
Tue Aug 15 16:26:41 UTC 2006

On Tuesday 15 August 2006 12:09 pm, mwoehlke wrote:
> Adam Treat wrote:
> > On Tuesday 15 August 2006 11:09 am, mwoehlke wrote:
> >> Hamish Rodda wrote:
> >>> On Tuesday 15 August 2006 03:59, Jakob Petsovits wrote:
> >>>> On Monday, 14. August 2006 19:17, Andreas Pakulat wrote:
> >>>>> On 14.08.06 17:00:15, Erik Sigra wrote:
> >>>>>> On 14.08.06 13:30:19, Erik Sigra wrote:
> >>>>>>> 2. kate is an editor it's not part of kdevelop and the kdevelop
> >>>>>>> developers have only partial influence on what the kate developers
> >>>>>>> use for parsing files.
> >>>>>>
> >>>>>> Kate is part of KDevelop when I am using KDevelop
> >>>>>
> >>>>> No it's not. KDevelop using Kate as the only implementation of the
> >>>>> KTextEditor interface doesn't make it a part of kdevelop, especially
> >>>>> not in terms of development changes. Kate is it's own project.
> >>>>
> >>>> There is a connection between KDevelop and Kate, and that's Hamish
> >>>> Rodda who is hacking both. For KDevelop 4, there have been some
> >>>> extensions in the KTextEditor interface which allow to integrate
> >>>> KDevelop's own parsers to a certain level, including highlighting.
> >>>> Hamish is working on that for the C++ parser.
> >>>
> >>> Exactly.  What Erik wants (or almost, seeing as we don't use ANTLR but
> >>> kdevelop-pg for kdevelop4) will be present in kdevelop4.  For
> >>> c++/c#/java (and possibly others) we will be doing the highlighting
> >>> solely in kdevelop.
> >>
> >> Hmm, so what is going to happen to KATE? As I pointed out, one of the
> >> advantages to the current system is consistency both inside and outside
> >> of KDevelop. Loosing that will be most unfortunate, or do you plan on
> >> porting this stuff out to KATE? (Or more accurately, will their be a
> >> text editor part with these features plus everything KATE does, that can
> >> be used in KWrite?)
> >
> > Nothing will happen to Kate.  Kate will remain as is, doing it's own
> > highlighting how it currently does it.  KDevelop will have enhanced
> > highlighting for the languages that it supports.  That is all.
> >
> > It is ludicrous to say this shouldn't be allowed because it
> > breaks 'consistency'.  IDE users want more involved highlighting.  Of
> > course, I suppose we could provide an option in KDevelop 4 allowing you
> > to turn off this feature.
> But it will. :-)
> What I'm saying is not that we shouldn't do it, but that KWrite should
> see the benefit too. KDevelop is too heavy-weight for one-source
> applications (i.e. most test programs). The fact is I do not - now, nor
> am I likely to in the future - use KDevelop exclusively for ALL coding.
> There are and will continue to be times that KWrite is much more efficient.

Ok, so you are talking about putting the heavy-weight kdevelop-pg parsers into 
Kate, thus making KWrite to heavy for your 'once-source application/test 
program' needs.  How does that help you again?

> I'm also trying to point out that you're violating the fundamental
> tenant of UNIX; make small, reusable tools. You're talking about making

See all of KDE.

> something that I think should be generally accessible only available in
> KDevelop. Again, the point is not "don't do it", it's "share with the
> rest of us". :-)

Ok, well again, you are talking about taking kdevelop-pg parsers and putting 
them in Kate, thus making Kate more heavy-weight.

> >> Will I be able to add new highlighting rules to KDevelop's C
> >> highlighting? Right now I have a custom .xml that 'IncludeRule ##C's and
> >> adds a bunch of project-specific keywords with their own highlighting
> >> style. Will I be able to do this in KDevelop4 without having to
> >> recompile? (Recompiling would absolutely unacceptable; what if I have
> >> multiple projects I want to do this for?)
> >
> > I'll let Hamish answer this, but my instinct says this is more trouble
> > than it is worth.  If you really need this, then you can just use Kate's
> > highlighting.
> IOW KDevelop will be "better" but less flexible? For as many problems as
> I have with KATE's highlighting (that is, almost none), that sounds like
> a poor trade-off. I think I'll be watching for that 'just use KATE'
> option... or writing the patch myself.

Yes, KDevelop will probably have enhanced, but less flexible highlighting.  
Sorry if you don't like the trade-off, but many people are looking forward to 

I love all the complaints for something that isn't even released yet. 



More information about the KDevelop-devel mailing list