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

[Hamish Rodda]

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

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/99d15a75/attachment.sig>