|Re: [cdt-dev] Assembly language keywords and directives|
You can have your assembly language implement IAsmLanguage and return your custom set of keywords or make it adaptable to ILanguageUI to provide your own code scanner. I don’t see a reason why there should be another way to provide your own scanner.
Within the AsmSourceViewerConfiguration#getCodeScanner, if we make the language adaptable to RuleBaseScanner, than it should be possible to provide your own code scanner.
Is this something acceptable? I can file a bug and provide the patch. The change is only a few lines of code.
We also have the same issue, multiple families for one debugger. One way to handle this is to have an assembly language defined for each family, you can associate a specific language to the project. This can be done during project creation. The only thing you will need to do is to provide your own asm scanner for each assembly language. I am looking in the case where I want to extend the standard CDT assembly scanner to provide my additional set of token highlight (keywords/directives, etc…). I think this is what you need as well.
This brings up a possibly more general issue of how people are managing the assembly editor. I know that at Mentor we had a single debugger that could target multiple families (ARM, PowerPC, MIPS, …) and the fact that there was not a flexible mechanism for choosing which assembly was in use was problematic (we ended up creating our own assembly editor). I think that ideally there should be any number of named sets of the keywords/directives (extension point?), and which one is used by the editor in any given file is an attribute possibly inherited from the containing project, or something like that.
As multi-core becomes more prevalent, being able to mix different families would be key.
Aaron Spear, VMware