[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-idle-dev
Subject:    [Idle-dev] IDLE "shell" (was: IDLE interpreter window)
From:       tim_one () email ! msn ! com (Tim Peters)
Date:       2000-03-09 3:53:04
Message-ID: 000601bf897a$f8e47380$0d2d153f () tim
[Download RAW message or body]

[Martijn Faassen]
> ...
> That's true for the general abstraction layer, but for IDLE, we can of
> course make our own fine tuned abstractions for whatever we want to do.

Indeed, Mark Hammond & I invented the (ill-documented, alas) notion of a
"virtual text widget" for IDLE, one of whose key abstractions is a query
function answering "is this particular character absolutely positively
guaranteed not to be in the interior of a Python string?".  Few GUI text
widgets answer that directly <wink>.

The motivation for this one is that auto-indent and paren-match (and "things
like that") need an absolutely reliable answer to that question, but it can
be unboundedly expensive to answer from scratch (in the extreme, it can
require reparsing the entire file!).  The cool thing is that IDLE and
PythonWin both already know the answer, thanks to the work they already did
for syntax coloring.  They do the latter in entirely different ways, but
given that any Python IDE will also do that in *some* way, assuming that
every "Python text widget" knows the answer makes good sense.

So that was a triumph.  Here's a failure:  another virtual text widget
method sets tab stops (for people insane enough to use hard tab characters
<wink>).  It turns out that had to be hidden in IDLE (but not in PythonWin),
because the Tk text widget itself doesn't support hard tabs in the way
people expect them to work, and it would be an incredibly amount of work to
fake it.

lowest-common-denominator-will-often-win-in-the-end-ly y'rs  - tim




[prev in list] [next in list] [prev in thread] [next in thread]