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

[mwoehlke]

Hamish Rodda wrote:
> On Thursday 17 August 2006 02:14, mwoehlke wrote:
>> 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).
> 
> Well, the macros are expanded by time the new highlighter gets there.  It 
> would be quite inefficient to reparse for this reason.  katepart might have 
> to keep doing this job for you (for now).

Oh, ok, thanks for the clarification. Anyway, yes, that's fine if it 
stays in KATE (now that we've clarified that will *work* ;-)). Like I 
said, RFE fodder stuff; it still seems we could add a list "by hand" as 
it were but it doesn't sound like there is any advantage to doing so at 
this stage, so no worries leaving it for later (or never).

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