On Thursday, July 17, 2014 10:23:50 PM UTC-5, Chris Angelico wrote:
> And be sure *not* to colorize built-ins (but *do* colorize
> keywords) in contexts where the tokens are actually
> identifiers, like "x.open = 1".
Just check for word boundaries on all your keywords and
built-ins and you're *DONE*!
> 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.
Stop it, you're embarrassing yourself with all this rambling!
You should have shut up a long time ago. Just like the
thread where you embarrassed yourself with your limited
knowledge of IDLE[1] and Tkinter, you're now really loosing
all respect as a competent programmer if you cannot even
write these "simple" regexps.
> 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.
Oh i get it now, your confusing Python with REXX again...
*face palm*
[1] Heck, you don't even realize that IDLE and an "acronym".
--
https://mail.python.org/mailman/listinfo/python-list
