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

[mwoehlke]

Hamish Rodda wrote:
> 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.

All you need is names, yes? I was thinking more along the lines of 
having a separate file sitting around with lists; anything not in the 
list would go in a default category (I would prefer a file because I am 
the only one using KDevelop on my project; adding things to existing 
files that only benefit me is therefore not an ideal solution). Or, as 
you say, I can keep working with my current solution of using a custom 
.xml (assuming KDevelop does not categorically override highlighting of 
user types).

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

Ah, well then thanks for keeping me informed. ;-)

>> 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.

Excellent. :-) And thanks again!

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