Issue with KDevelop: Is it using different parsers in parallell for different puropuses?
rodda at kde.org
Wed Aug 16 03:57:03 UTC 2006
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 :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the KDevelop-devel