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

[Hamish Rodda]

On Thursday 17 August 2006 01:11, mwoehlke wrote:
> Hamish Rodda wrote:
> > On Wednesday 16 August 2006 01:09, mwoehlke wrote:
> >> 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.
>
> Sounds great! Just to forewarn you, I will probably want to be able to
> create multiple sets of lists, so I can pick different colors for them,
> but that's obviously RFE material (of the kind I might tinker with
> myself). I'm just warning you in case it's really easy to "do right the
> first time".
>
> As an example (using Windoze; sorry :-)), I might want TRUE, FALSE and
> NULL to be keywords (I think these are #define's), but other macros to
> be 'normal text'. I might want __int64, etc, to show up as regular data
> types, DWORD, PVOID, etc to be a different color, and size_t to be yet a
> third color. I think all of *these* are typedefs. Anyway, that's a
> sample of how I am probably going to want to split project-defined
> keywords into different highlighting groups. I think this would be a
> great feature, especially for separating library keywords (types, etc)
> from application-defined keywords.

Hmm.. by time we do highlighting, most macro information is lost.  So this 
should probably remain kate's job... hmm.

> But, like I say, just a thought... feel free to not implement it (with
> the warning that I'll probably request it later :-)).
>
> >> 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.
>
> Sigh. Why didn't someone SAY so in the first place! :-)

I only changed my mind yesterday ;)

> I like that idea about 1000% better than total replacement, which was
> the feeling I was getting. Now it sounds like we're still getting KATE's
> highlighting plus a few project-dependent extras, in which case it is
> infinitely more reasonable for these to only be available in KDevelop.
> (Now... does this means I could also *still* use a custom .xml, and get
> the KDevelop features on top of that? ;-))

Yep.

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/20060817/f55f781e/attachment.sig>