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

[Hamish Rodda]

On Wednesday 16 August 2006 01:09, 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?)

As has been discussed, it is not within the scope of katepart to provide 
advanced highlighting such as this.  You simply need to know all of that 
stuff about your build system etc. in order to perform the parsing.  Kate app 
could decide to use our parser, and if they decided to do that we could make 
it a shared library.  However I'd consider this unlikely, whenever it is 
raised on kwrite-devel to introduce a parser, the response is usually (and I 
believe correctly) 'use kdevelop'.

> Also, what happens to files other than C/C++/Java? How will these be
> highlighted? Can I tell KDevelop to highlight any arbitrary file as e.g. C?

By katepart as previously.

> 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?)

As you guessed later on, kdevelop will be able to highlight custom types as 
you like them, so an equivalent functionality is being provided.

> Failing all that, will there be an option to let KATE do the
> highlighting for C/C++/Java anyway?

Sure.  In fact, I'm thinking about using the current katepart highlighting, 
and just overlaying the kdevelop highlighting on top.  That's how it works 
currently, and it would be a fair bit more work for me to fully replace 
katepart's highlighting.  I don't think there is a performance issue either 
then, and in the case of parsing failure, not all highlighting will be lost.

> I like the idea of better highlighting... but not if it breaks
> consistency between KDevelop and KWrite, or is less flexible.

If I design it as above (which I'm leaning towards now), then kdevelop will 
only add to the experience :)

Cheers,
Hamish.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20060816/e12818aa/attachment.sig>