I think that we can come up with very smart semantic rules (using type inference for instance).
When a plugin developer add a new semantic rule, it is automatically added to the PHP Syntax Coloring preference page. This means that no matter what are the rules and where they come from (PDT or a PDT subplugin), the end user has a total control on the syntax coloring. The end user can enable/disable rules and change the style associated to the rule. Use cases are the SmartyPDT highlighting, or PHPUnit special highlighting (for annotation, methods that are prefixed with test in a subtype of the TestCase class) etc. Let's get it right for PDT first, then we can worry about PDT's subplugins. Best regards, Wi On Wed, Aug 26, 2009 at 2:03 PM, Sjaak Eenhuis<excepti...@hotmail.com> wrote: >> I updated the wikipage about the PDT semantic highlighting: >> http://wiki.eclipse.org/PDT/Dev2Dev/Semantic. >> You can find the latest version of the patch on at this bug entry: >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=271430. >> I simplified the API so plugin developers can extend the editor >> highlighting in the simplest manner, without touching pdt.ui source >> code. >> >> Please take it for a ride and send me feedback and suggestions. >> > > Thanks. I wonder what higlighting points didn't you implement already? > I've been thinking how a plugin developer could do something useful with > these extension points. Normally the user wants to be in control about the > appearance and this possible via the preferences page, right? > > ________________________________ > Minder SPAM in de verbeterde Windows Live Hotmail > _______________________________________________ > pdt-dev mailing list > pdt-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/pdt-dev > > _______________________________________________ pdt-dev mailing list pdt-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/pdt-dev