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

[mwoehlke]

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.

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

Thanks for the clarifications, Hamish!

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

Sounds wonderful! :-)

-- 
Matthew
vIMprove your life! Now on version 7!