On Fri, Jul 18, 2014 at 1:07 PM, Rick Johnson <rantingrickjohn...@gmail.com> wrote: > For me, only the following targets need colorizing: > > Keywords > Built-ins
And be sure *not* to colorize built-ins (but *do* colorize keywords) in contexts where the tokens are actually identifiers, like "x.open = 1". Plus, if you want this to be truly general, you need to have it understand that some keywords aren't keywords if the shebang is different, although with 2.7 vs 3.4 that only really applies to nonlocal (if True/False/None are colored as keywords even though they're technically builtins, that's not a big deal); if you want to support Python 2.5, you'd also have to cope with a __future__ directive adding a keyword, but that's quite optional. It's not as simple as you might think. I've worked with plenty of syntax highlighters that get something wrong in some context, and it's extremely annoying; in some cases it makes the colorization actually harmful, rather than helpful. And it's absolutely *essential* that the lexer and the language agree on, for instance, what characters constitute identifiers; if I have a partially non-ASCII variable name and only the ASCII half of it gets highlighted, that can be highly distracting. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
