[Bf-committers] Syntax Highlighting & Alternate Languages

[Tom Edwards]

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