Home » Language IDEs » C / C++ IDE (CDT) » CDT extension for the POP-C++ programming language
| CDT extension for the POP-C++ programming language [message #211148] |
Wed, 05 March 2008 15:58  |
Eclipse User |
|
|
|
Originally posted by: matthias.spicher.edu.hefr.ch
Hello everybody,
For our semester project, my colleague and I have to write an eclipse
plug-in for the mentioned programming language. This language extends
the C++ programming language (i.e. 5 or 6 new keywords are defined).
The first step consists in creating an editor which does the syntax
highlighting. We searched the whole newsgroup for some information (and
found some helpful posts ;-)). What we think to know:
- we have to use the extension point org.eclipse.cdt.core.language to
define a new language
- we have to define content types for our file extensions (.cc for
source code files, .ph for header fiels -> .cc already exists from the
CDT environment, .ph we have to create)
- we can derive our language from the
org.eclipse.cdt.core.dom.ast.gnu.gcc.GPPLanguage class (since we have to
add only some keywords)
Unfortunately, there are a lot of things that we don't understand how to do:
- is the link between the editor and the new language created
automagically or how can we create it (because for the .cc files we have
to "force" the plug-in to use "our" language)?
- how can we define a new content type (in the plugin.xml file) for the
new .ph file extension?
- how can we add the new keywords in order that they are highlighted?
Thanks for your help
Matthias
|
|
|
| Re: CDT extension for the POP-C++ programming language [message #211203 is a reply to message #211148] |
Thu, 06 March 2008 10:10  |
 Anton Leherbauer
Messages: 490
Registered: July 2009 |
Senior Member |
|
|
Spicher Matthias wrote:
> Hello everybody,
> For our semester project, my colleague and I have to write an eclipse
> plug-in for the mentioned programming language. This language extends
> the C++ programming language (i.e. 5 or 6 new keywords are defined).
>
> The first step consists in creating an editor which does the syntax
> highlighting. We searched the whole newsgroup for some information (and
> found some helpful posts ;-)). What we think to know:
>
> - we have to use the extension point org.eclipse.cdt.core.language to
> define a new language
> - we have to define content types for our file extensions (.cc for
> source code files, .ph for header fiels -> .cc already exists from the
> CDT environment, .ph we have to create)
> - we can derive our language from the
> org.eclipse.cdt.core.dom.ast.gnu.gcc.GPPLanguage class (since we have to
> add only some keywords)
>
> Unfortunately, there are a lot of things that we don't understand how to
> do:
>
> - is the link between the editor and the new language created
> automagically or how can we create it (because for the .cc files we have
> to "force" the plug-in to use "our" language)?
The C/C++ editor is the default editor for all predefined C/C++
content-types (defined in org.eclipse.cdt.core/plugin.xml).
Languages are also associated with content-types, but this can be
overriden in the UI on the Language Mappings page (workspace preferences
and project properties). For .cc files you will probably need to
override the default association.
The C/C++ editor is language-aware in the sense that it uses the
interface ICLanguageKeywords to query the language for its keywords.
All predefined C/C++ language implement this interface.
> - how can we define a new content type (in the plugin.xml file) for the
> new .ph file extension?
Look at the examples in org.eclipse.cdt.core/plugin.xml
Important is that you derive the content-type from the predefined ones,
otherwise the C/C++ editor won't open by default for .ph files.
> - how can we add the new keywords in order that they are highlighted?
Extend method getKeywords() of the base language (GPPLanguage).
Or if you intend to have the keywords tokenized, specify them in the
IScannerExtensionConfiguration for you language.
How the parser will handle the new keywords is a different question, though.
> Thanks for your help
>
> Matthias
HTH,
Toni
--
Anton Leherbauer
Wind River CDT Team, Austria
|
|
|
| Re: CDT extension for the POP-C++ programming language [message #211542 is a reply to message #211203] |
Mon, 10 March 2008 11:57 |
| Eclipse User |
|
|
|
Originally posted by: matthias.spicher.edu.hefr.ch
Anton Leherbauer wrote:
> Spicher Matthias wrote:
>> Hello everybody,
>> For our semester project, my colleague and I have to write an eclipse
>> plug-in for the mentioned programming language. This language extends
>> the C++ programming language (i.e. 5 or 6 new keywords are defined).
>>
>> The first step consists in creating an editor which does the syntax
>> highlighting. We searched the whole newsgroup for some information
>> (and found some helpful posts ;-)). What we think to know:
>>
>> - we have to use the extension point org.eclipse.cdt.core.language to
>> define a new language
>> - we have to define content types for our file extensions (.cc for
>> source code files, .ph for header fiels -> .cc already exists from the
>> CDT environment, .ph we have to create)
>> - we can derive our language from the
>> org.eclipse.cdt.core.dom.ast.gnu.gcc.GPPLanguage class (since we have
>> to add only some keywords)
>>
>> Unfortunately, there are a lot of things that we don't understand how
>> to do:
>>
>> - is the link between the editor and the new language created
>> automagically or how can we create it (because for the .cc files we
>> have to "force" the plug-in to use "our" language)?
>
> The C/C++ editor is the default editor for all predefined C/C++
> content-types (defined in org.eclipse.cdt.core/plugin.xml).
> Languages are also associated with content-types, but this can be
> overriden in the UI on the Language Mappings page (workspace preferences
> and project properties). For .cc files you will probably need to
> override the default association.
> The C/C++ editor is language-aware in the sense that it uses the
> interface ICLanguageKeywords to query the language for its keywords.
> All predefined C/C++ language implement this interface.
>
>> - how can we define a new content type (in the plugin.xml file) for
>> the new .ph file extension?
>
> Look at the examples in org.eclipse.cdt.core/plugin.xml
> Important is that you derive the content-type from the predefined ones,
> otherwise the C/C++ editor won't open by default for .ph files.
>
>> - how can we add the new keywords in order that they are highlighted?
>
> Extend method getKeywords() of the base language (GPPLanguage).
> Or if you intend to have the keywords tokenized, specify them in the
> IScannerExtensionConfiguration for you language.
>
> How the parser will handle the new keywords is a different question,
> though.
>
>> Thanks for your help
>>
>> Matthias
>
> HTH,
> Toni
Thank you for your fast and very helpful answers! I was able to create a
new language and the associated content type (.ph). For the .cc
extension I did a language mapping. I tried both, overload getKeywords()
method and specify an IScannerExtensionConfiguration. Both solutions
worked correctly. I also downloaded the sources of the CDT project from
the CVS server because I tried to understand how this scanner extension
configuration works. But unfortunately it's still not clear. I hope you
will help me for these questions:
What is the difference between creating an
IScannerExtensionConfiguration and overloading the getKeywords() method
(I think that the first one must have some advantages)?
What is the advantage (or disadvantage) of having the keywords tokenized?
In the Pop-C++ language there is a construct that I also would like to
highlight:
@{ //some configuration stuff }
I would like to highlight this with a special color, and since this can
not be handled as a keyword, how can I do this (do I have to write my
own parser -> if yes, where can i find the parser that handles
multi-line constructs like comments (as an example))?
Is it possible to create a "group" of keywords? E.g. I would put all the
Pop-C++ keywords in this group and therefore it should be possible in
the "Preferences -> C/C++ -> Editor -> Syntax Coloring" to change the
color of only this group (to distinguish C++ and Pop-C++ keywords)?
Thank you for your help!
Matthias
|
|
|
| Re: CDT extension for the POP-C++ programming language [message #211550 is a reply to message #211542] |
Mon, 10 March 2008 16:05 |
Anton Leherbauer
Messages: 490
Registered: July 2009 |
Senior Member |
|
|
Spicher Matthias wrote:
> Anton Leherbauer wrote:
>> Spicher Matthias wrote:
>>> Hello everybody,
>>> For our semester project, my colleague and I have to write an eclipse
>>> plug-in for the mentioned programming language. This language extends
>>> the C++ programming language (i.e. 5 or 6 new keywords are defined).
>>>
>>> The first step consists in creating an editor which does the syntax
>>> highlighting. We searched the whole newsgroup for some information
>>> (and found some helpful posts ;-)). What we think to know:
>>>
>>> - we have to use the extension point org.eclipse.cdt.core.language to
>>> define a new language
>>> - we have to define content types for our file extensions (.cc for
>>> source code files, .ph for header fiels -> .cc already exists from
>>> the CDT environment, .ph we have to create)
>>> - we can derive our language from the
>>> org.eclipse.cdt.core.dom.ast.gnu.gcc.GPPLanguage class (since we have
>>> to add only some keywords)
>>>
>>> Unfortunately, there are a lot of things that we don't understand how
>>> to do:
>>>
>>> - is the link between the editor and the new language created
>>> automagically or how can we create it (because for the .cc files we
>>> have to "force" the plug-in to use "our" language)?
>>
>> The C/C++ editor is the default editor for all predefined C/C++
>> content-types (defined in org.eclipse.cdt.core/plugin.xml).
>> Languages are also associated with content-types, but this can be
>> overriden in the UI on the Language Mappings page (workspace
>> preferences and project properties). For .cc files you will probably
>> need to override the default association.
>> The C/C++ editor is language-aware in the sense that it uses the
>> interface ICLanguageKeywords to query the language for its keywords.
>> All predefined C/C++ language implement this interface.
>>
>>> - how can we define a new content type (in the plugin.xml file) for
>>> the new .ph file extension?
>>
>> Look at the examples in org.eclipse.cdt.core/plugin.xml
>> Important is that you derive the content-type from the predefined ones,
>> otherwise the C/C++ editor won't open by default for .ph files.
>>
>>> - how can we add the new keywords in order that they are highlighted?
>>
>> Extend method getKeywords() of the base language (GPPLanguage).
>> Or if you intend to have the keywords tokenized, specify them in the
>> IScannerExtensionConfiguration for you language.
>>
>> How the parser will handle the new keywords is a different question,
>> though.
>>
>>> Thanks for your help
>>>
>>> Matthias
>>
>> HTH,
>> Toni
>
> Thank you for your fast and very helpful answers! I was able to create a
> new language and the associated content type (.ph). For the .cc
> extension I did a language mapping. I tried both, overload getKeywords()
> method and specify an IScannerExtensionConfiguration. Both solutions
> worked correctly. I also downloaded the sources of the CDT project from
> the CVS server because I tried to understand how this scanner extension
> configuration works. But unfortunately it's still not clear. I hope you
> will help me for these questions:
>
> What is the difference between creating an
> IScannerExtensionConfiguration and overloading the getKeywords() method
> (I think that the first one must have some advantages)?
The difference is that the keywords get tokenized. Whether this is an
advantage or not is explained below.
> What is the advantage (or disadvantage) of having the keywords tokenized?
Tokenizing the keywords is necessary if you want to implement your own
parser (maybe deriving from the CDT parser).
If the parser does not understand the keywords/tokens, you will get
syntax errors, regardless whether they are tokenized or not.
Depending on the nature of the keywords, it could be sufficient to
define builtin macros (in the scanner extension configuration) that
simply replace the keywords by an emtpy string, instead of tokenizing
and parsing them.
>
> In the Pop-C++ language there is a construct that I also would like to
> highlight:
>
> @{ //some configuration stuff }
>
> I would like to highlight this with a special color, and since this can
> not be handled as a keyword, how can I do this (do I have to write my
> own parser -> if yes, where can i find the parser that handles
> multi-line constructs like comments (as an example))?
Customizations of this kind are not supported.
>
> Is it possible to create a "group" of keywords? E.g. I would put all the
> Pop-C++ keywords in this group and therefore it should be possible in
> the "Preferences -> C/C++ -> Editor -> Syntax Coloring" to change the
> color of only this group (to distinguish C++ and Pop-C++ keywords)?
This is not possible.
> Thank you for your help!
>
> Matthias
--
Anton Leherbauer
Wind River CDT Team, Austria
|
|
|
| Re: CDT extension for the POP-C++ programming language [message #211762 is a reply to message #211550] |
Wed, 12 March 2008 13:37 |
| Eclipse User |
|
|
|
Originally posted by: matthias.spicher.edu.hefr.ch
>> In the Pop-C++ language there is a construct that I also would like to
>> highlight:
>>
>> @{ //some configuration stuff }
>>
>> I would like to highlight this with a special color, and since this
>> can not be handled as a keyword, how can I do this (do I have to write
>> my own parser -> if yes, where can i find the parser that handles
>> multi-line constructs like comments (as an example))?
>
> Customizations of this kind are not supported.
>
OK, I understand that such a construct can't be added as easily as e.g.
keywords. But, I think there must be a way to highlight it anyway. The
question is, how can I do it? Or if it's absolutely not possible, why?
Have I to write a parser? Where can I find examples? Can you give me a
hint how to extend the CDT parser?
Or am I on the wrong way?
Thank you very much for your help!
Matthias
|
|
|
| Re: CDT extension for the POP-C++ programming language [message #211818 is a reply to message #211762] |
Thu, 13 March 2008 09:41 |
Anton Leherbauer
Messages: 490
Registered: July 2009 |
Senior Member |
|
|
Spicher Matthias wrote:
>>> In the Pop-C++ language there is a construct that I also would like
>>> to highlight:
>>>
>>> @{ //some configuration stuff }
>>>
>>> I would like to highlight this with a special color, and since this
>>> can not be handled as a keyword, how can I do this (do I have to
>>> write my own parser -> if yes, where can i find the parser that
>>> handles multi-line constructs like comments (as an example))?
>>
>> Customizations of this kind are not supported.
>>
>
> OK, I understand that such a construct can't be added as easily as e.g.
> keywords. But, I think there must be a way to highlight it anyway. The
> question is, how can I do it? Or if it's absolutely not possible, why?
>
> Have I to write a parser? Where can I find examples? Can you give me a
> hint how to extend the CDT parser?
>
> Or am I on the wrong way?
>
> Thank you very much for your help!
>
> Matthias
Well, it is certainly not impossible, but you need to change CDT code.
First of all, the basic syntax highlighting (comments, literals,
keywords, operators) is done independent of the parser.
Other highlightings require an AST (abstract syntax tree) which requires
a working parser.
So, if you only need the highlighting, you don't need to modify the parser.
Highlighting @{ ... } is similar to comment highlighting:
First, the partition scanner detects the basic "partitions" of the
source code, namely preprocessor directives, comments, string and
character literals. BTW, those partitions are not only used for
highlighting.
See FastCPartitionScanner.
Then, the highlighting is done for each partition type separately.
See CSourceViewerConfgiuration.getPresentationReconciler() where for
each partition type, another scanner is registered which in the simplest
case always returns the same token (=text style) for the whole partition
range, but it can also provide finer grained style ranges.
In your case, I would add support for @{ ... } in the partition scanner,
creating a new partition type and add a highlighting scanner for the
partition type in the source viewer configuration.
I am sorry, I don't have examples at hand. You need to look into the code.
HTH
--
Anton Leherbauer
Wind River CDT Team, Austria
|
|
|
| Re: CDT extension for the POP-C++ programming language [message #212068 is a reply to message #211818] |
Wed, 19 March 2008 09:20 |
| Eclipse User |
|
|
|
Originally posted by: matthias.spicher.edu.hefr.ch
Anton Leherbauer wrote:
> Spicher Matthias wrote:
>>>> In the Pop-C++ language there is a construct that I also would like
>>>> to highlight:
>>>>
>>>> @{ //some configuration stuff }
>>>>
>>>> I would like to highlight this with a special color, and since this
>>>> can not be handled as a keyword, how can I do this (do I have to
>>>> write my own parser -> if yes, where can i find the parser that
>>>> handles multi-line constructs like comments (as an example))?
>>>
>>> Customizations of this kind are not supported.
>>>
>>
>> OK, I understand that such a construct can't be added as easily as
>> e.g. keywords. But, I think there must be a way to highlight it
>> anyway. The question is, how can I do it? Or if it's absolutely not
>> possible, why?
>>
>> Have I to write a parser? Where can I find examples? Can you give me a
>> hint how to extend the CDT parser?
>>
>> Or am I on the wrong way?
>>
>> Thank you very much for your help!
>>
>> Matthias
>
> Well, it is certainly not impossible, but you need to change CDT code.
>
> First of all, the basic syntax highlighting (comments, literals,
> keywords, operators) is done independent of the parser.
> Other highlightings require an AST (abstract syntax tree) which requires
> a working parser.
>
> So, if you only need the highlighting, you don't need to modify the parser.
>
> Highlighting @{ ... } is similar to comment highlighting:
> First, the partition scanner detects the basic "partitions" of the
> source code, namely preprocessor directives, comments, string and
> character literals. BTW, those partitions are not only used for
> highlighting.
> See FastCPartitionScanner.
>
> Then, the highlighting is done for each partition type separately.
> See CSourceViewerConfgiuration.getPresentationReconciler() where for
> each partition type, another scanner is registered which in the simplest
> case always returns the same token (=text style) for the whole partition
> range, but it can also provide finer grained style ranges.
>
> In your case, I would add support for @{ ... } in the partition scanner,
> creating a new partition type and add a highlighting scanner for the
> partition type in the source viewer configuration.
>
> I am sorry, I don't have examples at hand. You need to look into the code.
>
> HTH
Thank you for the hints! Well, for some reasons we decided to not change
the CDT code. Is it possible, instead, to add a second partition scanner
and source viewer configuration? The idea is that first, the
FastCPartitonScanner and CSourceViewerConfgiuration do their jobs and
then, your custom scanner and viewer configuration do their job. What we
want is a modest syntax highlighting for
@{...}
constructs (i.e. if this construct appears in comments or strings, it
doesn't matter if its highlighted or not...).
Perhaps this is not possible, since you already thought about the
problem and gave me an answer. In that case sorry for the time that I
have stolen you. I just want to be sure if it is really not possible to
implement without changing CDT code.
Thank you very much, I am very thankful for your help.
Matthias
|
|
|
| Re: CDT extension for the POP-C++ programming language [message #212074 is a reply to message #212068] |
Wed, 19 March 2008 12:06 |
Anton Leherbauer
Messages: 490
Registered: July 2009 |
Senior Member |
|
|
Spicher Matthias wrote:
> Anton Leherbauer wrote:
>> Spicher Matthias wrote:
>>>>> In the Pop-C++ language there is a construct that I also would like
>>>>> to highlight:
>>>>>
>>>>> @{ //some configuration stuff }
>>>>>
>>>>> I would like to highlight this with a special color, and since this
>>>>> can not be handled as a keyword, how can I do this (do I have to
>>>>> write my own parser -> if yes, where can i find the parser that
>>>>> handles multi-line constructs like comments (as an example))?
>>>>
>>>> Customizations of this kind are not supported.
>>>>
>>>
>>> OK, I understand that such a construct can't be added as easily as
>>> e.g. keywords. But, I think there must be a way to highlight it
>>> anyway. The question is, how can I do it? Or if it's absolutely not
>>> possible, why?
>>>
>>> Have I to write a parser? Where can I find examples? Can you give me
>>> a hint how to extend the CDT parser?
>>>
>>> Or am I on the wrong way?
>>>
>>> Thank you very much for your help!
>>>
>>> Matthias
>>
>> Well, it is certainly not impossible, but you need to change CDT code.
>>
>> First of all, the basic syntax highlighting (comments, literals,
>> keywords, operators) is done independent of the parser.
>> Other highlightings require an AST (abstract syntax tree) which
>> requires a working parser.
>>
>> So, if you only need the highlighting, you don't need to modify the
>> parser.
>>
>> Highlighting @{ ... } is similar to comment highlighting:
>> First, the partition scanner detects the basic "partitions" of the
>> source code, namely preprocessor directives, comments, string and
>> character literals. BTW, those partitions are not only used for
>> highlighting.
>> See FastCPartitionScanner.
>>
>> Then, the highlighting is done for each partition type separately.
>> See CSourceViewerConfgiuration.getPresentationReconciler() where for
>> each partition type, another scanner is registered which in the
>> simplest case always returns the same token (=text style) for the
>> whole partition range, but it can also provide finer grained style
>> ranges.
>>
>> In your case, I would add support for @{ ... } in the partition
>> scanner, creating a new partition type and add a highlighting scanner
>> for the partition type in the source viewer configuration.
>>
>> I am sorry, I don't have examples at hand. You need to look into the
>> code.
>>
>> HTH
>
> Thank you for the hints! Well, for some reasons we decided to not change
> the CDT code. Is it possible, instead, to add a second partition scanner
> and source viewer configuration? The idea is that first, the
> FastCPartitonScanner and CSourceViewerConfgiuration do their jobs and
> then, your custom scanner and viewer configuration do their job. What we
> want is a modest syntax highlighting for
>
> @{...}
>
> constructs (i.e. if this construct appears in comments or strings, it
> doesn't matter if its highlighted or not...).
> Perhaps this is not possible, since you already thought about the
> problem and gave me an answer. In that case sorry for the time that I
> have stolen you. I just want to be sure if it is really not possible to
> implement without changing CDT code.
>
> Thank you very much, I am very thankful for your help.
>
> Matthias
I would not say it is impossible without changing CDT code, but you will
certainly need to derive from internal classes and depend on
implementation details, but if that's OK, here you go:
1. To customize the partition scanner:
You can override the partition scanner by implementing and registering
your own "documentSetupParticipant" (see org.eclipse.cdt.ui/plugin.xml).
The Document setup participant initializes the partitioner for new
documents.
Document setup participants are registered per content-type, ie. files
of your language must be associated to a unique content-type.
It is also possible to attach a second partitioner (with a different
partitioning key). I am not sure what would be the better choice, though.
2. To customize the source viewer configuration:
Implement and register (plugin.xml) you own editor (derived from
CEditor), override the initialization of the source viewer configuration
with your custom one (derived from CSourceViewerConfiguration).
3. Voila
Disclaimer: I did not try all that...
--
Anton Leherbauer
Wind River CDT Team, Austria
|
|
|
| Re: CDT extension for the POP-C++ programming language [message #212801 is a reply to message #212074] |
Thu, 27 March 2008 10:16 |
| Eclipse User |
|
|
|
Originally posted by: matthias.spicher.edu.hefr.ch
This is a multi-part message in MIME format.
--------------080901080405090300070000
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
>
> I would not say it is impossible without changing CDT code, but you will
> certainly need to derive from internal classes and depend on
> implementation details, but if that's OK, here you go:
>
> 1. To customize the partition scanner:
> You can override the partition scanner by implementing and registering
> your own "documentSetupParticipant" (see org.eclipse.cdt.ui/plugin.xml).
> The Document setup participant initializes the partitioner for new
> documents.
> Document setup participants are registered per content-type, ie. files
> of your language must be associated to a unique content-type.
> It is also possible to attach a second partitioner (with a different
> partitioning key). I am not sure what would be the better choice, though.
>
> 2. To customize the source viewer configuration:
> Implement and register (plugin.xml) you own editor (derived from
> CEditor), override the initialization of the source viewer configuration
> with your custom one (derived from CSourceViewerConfiguration).
>
> 3. Voila
>
> Disclaimer: I did not try all that...
>
Hello, you're great!
Almost everything works, but there's still something that I don't find
out how to do.
What I did:
- creation of a DocumentSetupParticipant (definition in plugin.xml)
- my DocumentSetupParticipant class calls setupCDocument of my TextTools
class
- overload the getPartitionScanner method in my TextTools class (derived
from CTextTools) -> the method returns my PartitionScanner
- for the partition scanner I used the same code as for the
FastCPartitionScanner, but I added some code.
This part seems to work correctly. The problem is in the following part:
- I defined an editor in the plugin.xml file
- my editor (derived from CEditor) calls setSourceViewerConfiguration at
the initialization -> my SourceViewerConfiguration (derived from
CSourceViewerConfiguration) is given as argument
- I think in the source viewer class the most important method to
override is getPresentationReconciler -> I did it and registered a
scanner (derived from AbstractCScanner) for the DefaultDamagerRepairer
All this seems to work (if this is the correct approach...).
The problem is that no coloration is done for my partition. My idea was
to bind() a color to a string in the IColorManager. The same string is
then returned by the getTokenProperties method of the scanner. But
nothing happens. I tried also to call the setValue method of the
IPreferenceStore, but that returns me an UnsupportedOperationException.
Can you tell me what I did wrong? Did I forget something?
If this explication is not clear, please see the attached code.
Thank you very much. Have a nice day!
Matthias
--------------080901080405090300070000
Content-Type: application/zip;
name="files.zip"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="files.zip"
UEsDBBQAAAAIADBwejiMBn7JuAwAAHM8AAAdABUARmFzdFBvcENQYXJ0aXRp b25TY2FubmVy
LmphdmFVVAkAAytJ6kdBcetHVXgEAOgD6APtW2tz2zYW/Sz+CjSZqaVYlu30 sTvWaLcKo7Ta
dWyvpMzuTJPR0BQksaFILUn50VT/fS+eBECQohw76Yd1Z1ITxD24uI+DCxA+ fvG4Pw56gdx4
fZ8Ei2WGmn4LvTw5OWmTf39Ew1dv4WWyjhMvC+IIedEMxdkSJ2mHyPXDEFG5 FCU4xckNnnXQ
ZBmkaJ3Ei8RbUQHojzzfj1drL7oPogVaeRlOAi9MCYaXYGiYQZcbLwi96xCj TTTDCRWDfqsU
xXP6MPDDYJ1idLW5DgMfnQc+juDx5rRzQoBul4G/lAMFOAUh0GQWpFkSXG+I /m2qDzTmY3kZ
kV1m2frs+Pj29raD2SidOFkch3jhhcd4HR7dnJ50ltkqhM7MYBEDjZP0jDSQ H9NYRyiIggzm
ifpXQzbyah3iFY4y2kHI/eviP2gcz7NbYorxfZrhlXjVjzIAOsdg8WtvA0Zp /jsAnFFwA7+z
rmmLdKZKLb1oAdOexwm6itdH7uEhGswC0FGqOF6DjUD0rZeBcbwUNd9FBCsN snti5v56HQZ4
hsZ+gCMfp230BqYZb5IFGeVxf46dted/9BYY+csODuaddbz2u47jgJXiJEPg AOmM3+aejzsZ
vss6r7zZeexTAw7ufLwmv3R3yAxfx/6G2H1Xx2QT4rQzBEsmng/BN/a9KMJJ TbErL8kCos8k
/oij/WSpSL2+vKutrz/LOkEEikde2NkE3GKb+RwneCaMUKUYARByQ1dOKCV+ OWZkQfM7ZRiQ
9n68iILfabZh5KLVJswCFAYRuDVekeEgiFyUQt5DtuntNGgRSc9oQXv5wu4p TRcXaAQDk0Ag
phDTswBGyyBcKflA+DAemAcwWeSHXpqiN16aQejnivO55pmXIrub2kidLvrk OA0y3wadMEbB
DGSDeQBQ8fVvoAaa4dRPAhp+aC0EYW5g/ShD2f0ad4j0sdPgeqYk64W6Yzpp dHV55U4vX/1j
4E6mrwdjdzS8mgwvL3ro2XRK0mHKBpsqgz3rOg3Q7Zji4RTgk+AGftPxIQiQ 616+HvTQSbdR
0Wk8vPj5fDA9H14Mpu7l27eDi0kPnXYrJN6+O58MDYGXVQLuL/1R350MRj30 XVW/8WQEyvTQ
91WdrkaDq9GlOxiPLwHvh7pdpzatf6ySLnoF9dBfhPGv8SKIIuJCYE2I0nlw h1nQruM0o08V
2BeXF9QxFV1e9d1/js/741+INxCMyHEpuzNLtXPL0pEtrqyyNgN/ycDpDBh2 jgLMoHh7F9Z0
POlTFxuARctXxgDB+L4w471A3P5oNOz/PJiOBpN3o4veD09iQOmhqTsisfQU Y/QnNOgaEHKK
RYsMVAkxveqPAOav3d0olPQo4XGC7zAG4+AMtWQ9QXP+Sw9F+LasV/MUqssW UQXNgaxVavZM
HeL5PMWZKP+A4DNYb7JNEkGFkhHu1rUjs51TTr+kgt0cKcTRIls+AOmcCnY1 yxDeFVCKmRqG
/Jj0U3Ugo6YBrJbzAKQydbVLsDezqHAOIgqCt4o3EbWHulCGRPieQiBYgeZB AuP4HpTmWQye
uMvoRJotC/4VjQY5RzLOMJqBdtDhdolJoY/8TZJgri0pnRl+FEdHUHDDAgRF HGYvYXBqXVjj
1ZGu4zjEHij2hkiS0uoyOoc+PZQlGzAQ5VMMdQPpXFi5LTgD1rcHARSmuGvM yXXjGZYBUHyl
eFQPa1aC/fqBez5lYSxbPzmNBmlg1ow2Ydhqa03u1JLbhT5FIit0kYRRHIBS SqFZXej2eVlS
fbScxpa4hdctZTVVUziE+65FTEQ2GbmD+Bsw9rYGngQg+7YmdW6Lix6zSuyn FOM6dTRHfK5E
v16LsW5qdtCKb0ckNoI5aorZUW15kxJz6JseOjpF336rURE61PiEdNKEDrXg 5NANHaFnUhL8
MBITEfsrrfg+0FdbhMF+AkgZi6jXVVoZHKtGQMxpUIPvHFt97plMAu+BHKDe b5IU59PJlySf
SHCrdghvNVt08LyXCK0gLZCGSSNd6QXjBfGBT019AP/lD++zA2ngIjqnFGYJ Eg851UIINRrp
bZABUNNnXoIW3wM7F7aMncHlmzOAQFw51ft/QydMA0R0ICTfoyUhLSFggYgT tlrwHtzJsHS/
Ce6abF1ps+q+TeXagEeNjjS/m+iiSfWV8LschepJlOfdSTCISR68Tw7OHAZS Qub0JZnwNyJP
aCoQLVCvl9dMwnhSQ7Wa4hqpNjs87Dq0e4PssIJIjsXnWzIk+NsoBoXr5cDG +654awzeqBpd
zIUUNUKHP/7Ip22MwYYQkcQcKvWilrasJGfKa7lCqI1scVBbVOrn7RXBSH84 MdKaqCd5han4
gcYYC6IdRJkPpbOl3bSiXY9V3miPVoPgdvuzgHSaIzniNzbPHsst+Z5nRsaP XezDQ2CkUOdy
JjNCRRtmhufeJsyEQwqChtyWR5qWh+9FHlIbV2SXio4MdJSjXwMLf+xqQ0Q7 U700hqtD2BbB
hQAui1+IOy9NcZIVg7gre4BRaLFNq9JbD2pkdO35H1NoXJISNUK3GC29G6io oXqBEn4N2wBS
tjp53Ar6kDbVSEVlqzy0BVHDJjBn6pb0o1P0vul83fdMRJMop9YynvvSNCN4 Btb5kG1f5DNU
nmJTpKnmL3Mbsug7PhDp0QhpVlNjy9QSQGamyjBWoF4UoCb90YOQ3h+YUBpV KVDCbpVwz2qi
MYNXa5aYWGUsuNd835uoMuwfhPe85oTVeCoBNDh0hztsmrEHSf0lVRhtNrJb L8PEMG0a7W10
2hJKshQiY6trL8Q7JCvYgiRvobxVlskaGtGk8uNws4qUgnqBM5e2wabmSFnm NMI86nFB+XpH
YVAyfdVXohhlwLCnOc0Xw8Jq/UCcGnsic66F3YnopEUCq/eV/2sBZ8SbKrl1 5L8smuTRfANp
OwaFgFExOopcaDChttLnq7zdd0cIooB0Zs9MsGW4VPco309YlgThj5fSDaY3 HwBRz5F1/Ggk
dMOxqWivOXmOaZRm+FZxxYsv7IriUVFbOWmv74/6OE/mFKtPCpVvMa1U8+fL 725qrCYzq7Xl
oi1iVbKOoXZdsVrGrGFL3SqKQZ7VsYc0otUmaIdRxDeMfSxSIvM05jCD5Lma o1qhXLHW7rOM
Vq+iOxbRz1pDS5J83xX0yXjX7pCfZJDaGJhHbn/Cn1VMBeSTlXn7kyeh3eKB eJt/RKtPufUw
/qR0y77NhWG2TOLNYknbqretChIDKpwn2Hea5HiheKBa2H7wKLEedPydhjo6 K+xNrPFmxBeq
mhhSBarOSoxjiq81qX2Lxup4+Erl09yyB7R8M+s+YA414//xY8Kif3XN/6IO ZyrHGEKh3REA
MtW21s1Rlue1KaHBKUVjBWZoYak/qXGMszzLZ9uHRdljmk4exX1tHpVDQUlK R0ZCz7LT1PyE
2rQ0/8YtvmeZH7R0a2n5KBKS/P8zE1kxsnoIarHzFzGz5s4DcTC/t2nziwUS cw/zIhnBqDKE
d5lWxgadT7FSqk7/rbCyMTfLNYbPJyrEP4gjBzW20KPimpVebYrTb6a7mEve oqrEJ0K+yjt8
liRG1Hfsq5d4a5ztnol2GQGyxXgCgpMP/Yk6gDJ2fjJQBJ66KgApZ1WQlxRk 2+C3PbTLNTdx
MEPS9NQGxYhX97EUpeSOjnQ6MXOaf9aoRnQs3/cKXxeplY1bFSn/+GmZltCH Ff9SnTZSP3ew
J3Y8TH5bK2Myxfe4dkK2suwGWo/Pg7TU3vuIuxjGLtbWn8acfnPEuF1nXiEp bF/0rQvbQwsf
aB+DDD+szT0O96P8oFTiIUdfjuvP0oDfpY79K7mMk5JJ6t+RKbVsi5TCyYSK Nfk1cX6rfHK/
xvyiEv2UkLeSYKBX0pRxeJBDi7whoUh08H83XpiW3FpTcSzva6BaCiYV1FbS 79aUlQaacvzj
2E7ZfO3TbJR/qduJoF2kU0HM+nkHUtmtOxWy+FqsAAS56OTCJTn7Hzk8h7yl L7xwRP5WqCn/
MIYyE/+HBR19MK7NURYvxUAzFYzf3uXkR3NHQKvxzClRaMu4hQe5PIuDJjZW PoJAZ8g0jVV2
6pmQeQftKomR6fzG8ZFVWl9LeBJyiV5hQM60QO0JhtROMuRlxp8NCAGVMeTS pBEZfyl5QSUE
XrvQU58suefXEnccaTKWKtzs4AeGMJsTcoFJmJtI8pkesS7ibLHVAY+umq0O 8wMs7T1u2S3y
PVr12P5gC+E7XyxFpddLtszK+9/JtF53tNx23FryxkyX0jwpSY19c+IxQj0u jXBqQNsVqurC
6P+R9NiRBNNWXGNeR+ZrvtaDKqDVObIAqTcU07pqKNGjOJRkPRhq6/wPUEsD BBQAAAAIAFZA
dDiBkWnU2gAAANgBAAAhABUAUG9wQ0RvY3VtZW50U2V0dXBQYXJ0aWNpcGFu dC5qYXZhVVQJ
AAMUDOJHQXHrR1V4BADoA+gDjY/BTsMwEETP9lfsMb34B6Ke4FLBIRL9AXez bhccr2VvAAn1
30lCFYREEBfL0sy8nckeX/yZAC+OOLgsGVtrechSFKScHWHkXMmhFHKBI53G EKhUd7gXHAdK
+kQ65s4XZeTsk7b/ij8KemVJD5z67UQZk/JA7tB5vfxqew4eySm963ejaUEe T5ERMPpaoZN8
t9UWJmakWamwOQk+rDU35F+wZjc5jbHmas0aeBXuoc7OZj0A/e3zFZiZx2nC USRW0OXdQ6I3
+KE0u3YyL7JbgGuRZuW18/Gr/QRQSwMEFAAAAAgARkB0ONENphkRAQAA7gEA AA8AFQBQb3BD
RWRpdG9yLmphdmFVVAkAA/QL4kdBcetHVXgEAOgD6AOFkMFKAzEQhs/Zp8hx F0peoAjC1oMH
caHVe5rMbgfTTJhMWlH67matLYiKp0z4v3/+mUnWvdgJtNsZwNEkSm7ZNLhP xKKJJwMuYMpg
nBeDUYCjDaagAY9CbPq7z3f5l6WS/dP9EMqEsTZOZRvQaRdsznqg9GXX8CoQ fdaX/3ujbh8P
wIweGpWYBJyA1wdCrzGioA34Bme67WZe5ZKAzU9xWbU5alNDNkQha7lWNzrC UX9Tz4YMsqbC
Dp4RjsA9xRGnwlaQYlt1pS7GfzClrmlmAukpED/YWG9eR1vo63FmcQWjLUHa 7kzutxjBDwwj
MEQH67oOzCbZYV7o39qvyJU9RBksC85DYJzarptXOjWn5gNQSwMEFAAAAAgA UlZ7OKV5ZlG8
AgAA6gYAABAAFQBQb3BDU2Nhbm5lci5qYXZhVVQJAAPsbetHQXHrR1V4BADo A+gDrVRdT9sw
FH1ufsUVe0lRcQpj0gRCGl+aKsHUUR4mIR5c5yYxuHZkOy0M8d937ZTwVcY0 YaWp7Jxz7/U5
vs7WP3YksA6Hpr61sqw8pKIPW8PhMLy+wOjglL7Z2ljupdHAdQ7GV2gdC7R9 pSDSHFh0aOeY
MzivpIPamtLyWSQQHrgQZlZzfSt1CTPu0UquXIjBLdJCTpA5l4pPFUKjc7SR RriZA1PEybFQ
snYI42aqpIATKVDTdL7JhiHQopKi6hJJdESiSnLpvJXTJtQ/iPXQ4mMu7gO3 8r7eybLFYsGw
zcKMLTOFJVcZ1mpjvjlklZ8pArd66TaosW4nLITxUqwNkFp62ifsj0dt5lmt cIbaR8AD7+eP
XzAxhV8EKSa3zuOMPn3syJKai2teIoiKoSxYbWqxmyRUkbEerkgQRhIpdkJy Pa6TCJ0gIvdM
anJEc8UayTzeeLY/JXW58IcTwbVGu/vPzNGhUcaeck1F/S/t+MbTESAp3+QT bWyxQItaILnm
PNferYRfFVwgqzs0Gz0yJ2Q0/oXVlnZkRBPcfQ9oG4WOjc7NNa6u/BX2bahb eEadVtPhd+zs
+wF5l2RtU9OPbG+bpZAkIgjFnYOxqR/sAgwK5g5e+niX9JIeNbFH4TGHtlYo jrDgjfJn6Bur
l0URTM6po2FCLaHLi0soxtbUaP3tbozSVvAka/rMROr++D+Al4KDC+/BMnC4 U2LUPlB1PdfQ
JO24S+jWsE9Je2m6+pz0l/g+m0qdR0i6FlphbQAaF0ACplufvw62t+npx1Dd ZvYiotvkXVcP
3Afcstflb0wD7z5Jetl60iMfvjnEVwJ/KtFHAZfh6b5K+wGePdW9y7YKHWWw 0Ypnkr+bWlgk
v87CyVqRM9wA8AwSE63wfq8rK+3yXwwvo2wO/WtCuiJIRC93oRul2g3QkyR/ AFBLAwQUAAAA
CABHVns4UdwaLhcEAACDEQAAIgAVAFBvcENTb3VyY2VWaWV3ZXJDb25maWd1 cmF0aW9uLmph
dmFVVAkAA9Vt60dBcetHVXgEAOgD6APtV9tu2zgQfZa+guiTnHrZDwgC1JHV VkViC7ZaYLFY
GCw1srmrSAJJOQ0K/3tJSdEtlG8v+7JBYPAyc2Y4wzkc5YT+S7aA6A4Di3Ge 5fTWttlTnnGJ
Mr7FQBOWC8A0kpilEnhKElwwLOGnxLMfQnJCpbumJE2B356t6QYcBKSSSJal K6BZSllyEcA6
KziF7wyegbtZGrNtwUu08zF8182STGsLSVIpLtHUio8kVbG7wOmemvdTQiou cliFSeqgCcGE
CoFbTWflNOAZBSGyC9wZwPXRIAYOKYVROIXiegk8KZ1aVbmwZ9GRgCiVFvh0 2NuwBYRLppNr
Fv4nJhRw3kBjvzWzlhk3H6LSqizMM1rok5wSPBIycqm2f0H+zgQ5wweWxhl/ KisF+347qQty
JHtnARzJ/pj+FfbzDnOUiT6XRzoYvEhA4DnEpEjknDzpelxBThg/V3elfu+J gOgY9XW0RElX
2O/S1hGdQrJE1UqWA5cv7o6kW/D2Y/dTPEu85STfMaoc+3xvFKqLCSKmCgL7 oRp75VjxfV78
SBhFNFGXCgVZPk6uSEOkkUBHRH7Zlm19uLmxLXSDwh1oxD/c9++RqEKF9cYH 28o52xMJaPiK
oLh04TWuCqz276hnTo9cEe1Mpsi2LGvICSjvz6eoExRUxWmK1pKzdIvyVwJS k4k+oSUKlRun
b+YN4itKT10dyeoe8Q6l8Iw6C84WZPcwzqQ6gdIaGninX+x3GvJQBopnEqhK MhreT6Qwuyaq
Q3CQBU+HAS+hPi73wLkq6Cb8RrbQuMtCJiyFZs3p3XIkOpPKbMzUM4SMcHkz ukOOSWJSBh6b
zPYM3bZ2DCSl7NSDKvojL5nORHUhnIlCRPVf4yQWIA3oziv6FH0ioox784LV YcbBMnA3y/uv
nhtu5t7aXflB6C8XHSt1cvKWGC/OzBcGnHC6e/k/N/9ZbswvVFmPxp2TGRrp nZVPzfCu5Atn
RLJN04gHb5Kl/s2PJYpq+jJvO0PWKdFaR3WOahUnui4jQ7jG9NV4LS/yTkMx lt/qgfjrb1SS
dvUgQVTf1fAlB3EyobU1HcYG7ReySspvOlM89z7Nvj2EG3e5CL1FuAn/DLz6 Xeg2yNjdPCox
f/PgLzwl/PiohKcmsbW/+PzgnSEXrpSkccv9MlvN3NBbGXeDlReslq63Xi9r gUvzcThSV8PG
t05Ab+1k6FmMujyC7tRtLpKk2mwSo1b0xTjYuvqGZkkzUqw43G1L7Y1rpiIb +STQjFiPqsou
adEs2z3OtHfiaevqlZXR6OtCGzHfuHqVjbYaSPtBM3YF9hmLkOqNowQMrbJj WEOgfzsNHB5X
r0Rv60vSbZEwiWPVZYl72JE9U2euRCe21W/sMIlILsOs881b4rfQB/tg/wZQ SwMEFAAAAAgA
WEB0OKjCSqKlAAAAHAEAABIAFQBQb3BDVGV4dFRvb2xzLmphdmFVVAkAAxgM 4kdBcetHVXgE
AOgD6ANtjcEKwjAQRM/NV+xRL/sDPQqCt4L9gbjd1mjchGSDgvTfbbGoYC/L MjNvJlq62oGB
zsiuxxgi1ca4WwxJIaQBmbyLmZE6RSfKSazH4lD5obhrp9uG4HO9xlx6S/xO puI546GxSZ26
IG24shzJinCaBmM5eUdA3uYMTYjfYpgeli7Dj/Q01QKsF8LA+jEWbbOdsSqx liQgfIe9zTpP
/SdrU41mNC9QSwECFwMUAAAACAAwcHo4jAZ+ybgMAABzPAAAHQANAAAAAAAB AAAApIEAAAAA
RmFzdFBvcENQYXJ0aXRpb25TY2FubmVyLmphdmFVVAUAAytJ6kdVeAAAUEsB AhcDFAAAAAgA
VkB0OIGRadTaAAAA2AEAACEADQAAAAAAAQAAAKSBCA0AAFBvcENEb2N1bWVu dFNldHVwUGFy
dGljaXBhbnQuamF2YVVUBQADFAziR1V4AABQSwECFwMUAAAACABGQHQ40Q2m GREBAADuAQAA
DwANAAAAAAABAAAApIE2DgAAUG9wQ0VkaXRvci5qYXZhVVQFAAP0C+JHVXgA AFBLAQIXAxQA
AAAIAFJWezileWZRvAIAAOoGAAAQAA0AAAAAAAEAAACkgYkPAABQb3BDU2Nh bm5lci5qYXZh
VVQFAAPsbetHVXgAAFBLAQIXAxQAAAAIAEdWezhR3BouFwQAAIMRAAAiAA0A AAAAAAEAAACk
gYgSAABQb3BDU291cmNlVmlld2VyQ29uZmlndXJhdGlvbi5qYXZhVVQFAAPV betHVXgAAFBL
AQIXAxQAAAAIAFhAdDiowkqipQAAABwBAAASAA0AAAAAAAEAAACkgfQWAABQ b3BDVGV4dFRv
b2xzLmphdmFVVAUAAxgM4kdVeAAAUEsFBgAAAAAGAAYA8wEAAN4XAAAAAA==
--------------080901080405090300070000--
|
|
|
| Re: CDT extension for the POP-C++ programming language [message #212931 is a reply to message #212801] |
Fri, 28 March 2008 09:28 |
Anton Leherbauer
Messages: 490
Registered: July 2009 |
Senior Member |
|
|
Spicher Matthias wrote:
>>
>> I would not say it is impossible without changing CDT code, but you
>> will certainly need to derive from internal classes and depend on
>> implementation details, but if that's OK, here you go:
>>
>> 1. To customize the partition scanner:
>> You can override the partition scanner by implementing and registering
>> your own "documentSetupParticipant" (see
>> org.eclipse.cdt.ui/plugin.xml). The Document setup participant
>> initializes the partitioner for new documents.
>> Document setup participants are registered per content-type, ie. files
>> of your language must be associated to a unique content-type.
>> It is also possible to attach a second partitioner (with a different
>> partitioning key). I am not sure what would be the better choice, though.
>>
>> 2. To customize the source viewer configuration:
>> Implement and register (plugin.xml) you own editor (derived from
>> CEditor), override the initialization of the source viewer
>> configuration with your custom one (derived from
>> CSourceViewerConfiguration).
>>
>> 3. Voila
>>
>> Disclaimer: I did not try all that...
>>
>
> Hello, you're great!
> Almost everything works, but there's still something that I don't find
> out how to do.
>
> What I did:
>
> - creation of a DocumentSetupParticipant (definition in plugin.xml)
> - my DocumentSetupParticipant class calls setupCDocument of my TextTools
> class
> - overload the getPartitionScanner method in my TextTools class (derived
> from CTextTools) -> the method returns my PartitionScanner
> - for the partition scanner I used the same code as for the
> FastCPartitionScanner, but I added some code.
>
> This part seems to work correctly. The problem is in the following part:
>
> - I defined an editor in the plugin.xml file
> - my editor (derived from CEditor) calls setSourceViewerConfiguration at
> the initialization -> my SourceViewerConfiguration (derived from
> CSourceViewerConfiguration) is given as argument
> - I think in the source viewer class the most important method to
> override is getPresentationReconciler -> I did it and registered a
> scanner (derived from AbstractCScanner) for the DefaultDamagerRepairer
>
> All this seems to work (if this is the correct approach...).
>
> The problem is that no coloration is done for my partition. My idea was
> to bind() a color to a string in the IColorManager. The same string is
> then returned by the getTokenProperties method of the scanner. But
> nothing happens. I tried also to call the setValue method of the
> IPreferenceStore, but that returns me an UnsupportedOperationException.
> Can you tell me what I did wrong? Did I forget something?
> If this explication is not clear, please see the attached code.
>
> Thank you very much. Have a nice day!
>
> Matthias
Some hints:
The PopCScanner should be a SingleTokenCScanner if it does not implement
a rule to scan the partition. Otherwise the token length will be 0.
The CTextTools (and therefore als PopCTextTools) should be used as a
singleton instance, otherwise it will leak resources.
HTH
--
Anton Leherbauer
Wind River CDT Team, Austria
|
|
| |
Goto Forum:
Current Time: Fri Apr 26 11:32:57 GMT 2024
Powered by FUDForum. Page generated in 0.04380 seconds |
] 
Search
Help
Register
Login
Home
