There's no reason to keep the keywords list as a Python var. Who needs constant access to it? It can be converted to a native C vector/array/whatever immediately. Any highlighting extension that isn't scriptable isn't worth doing IMO.
On 27/07/2011 9:25, Benjamin Tolputt wrote: > I'm pretty sure that putting the parsing code into the Python layer > would slow the syntax highlighting code quite dramatically and, as > such, is not likely to get the core team approval (let alone be > appreciated by the users). I like the idea of that kind of > flexibility, but the code is currently quite low level & speedy > (integer comparisons from a char array). The speed hit to jump up to > Python (with the string passing, Python string comparisons, and return > path) is most likely going to rule this out almost completely. That > said, in terms of the priority request, I'm willing to do the > low-level code stuff myself. This isn't a request for other developers > to code something for me, it is a request to pre-check whether it is > worth putting the code together myself. It is contained in perhaps two > files, there are no changes to the API required, and it is very close > to a copy/paste job with alternate means of detecting comments, > strings, and special strings. The changes are small, there is no > performance penalty, and the upside is (for people like myself) quite > high. If I cannot get approval for this - I don't think integrating > Python would be worth mentioning ;) _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
