IDLE in any other GUI.

[Just van Rossum]

[Tim Peters]
>The "deep" parts shared by IDLE and PythonWin are pointed to in IDLE's
>EditorWindow.py, following the comment:
>
>    # Tk implementations of "virtual text methods" -- each platform
>    # reusing IDLE's support code needs to define these for its GUI's
>    # flavor of widget.
>
>PythonWin uses an unrelated text widget, and so implements the methods
>following this comment differently.  All of the stuff for parsing Python
>code, suggesting indentation (which is now as smart as the Emacs pymode --
>which means "very smart"), and doing various reformatting are written in
>terms of these "virtual text methods".  So while it remains woefully
>underdocumented, in practice it will prove easier than you fear <wink>.

Phew... I'll look into it again. Maybe it's also possible to factor out the
Tk-dependencies of the object browser, if there are any in the first place.
I meant to study Guido's tree widget stuff for a long time: apparently he's
come up with some neat stuff...

>There's one huge compromise:  IDLE uses Tk-style text indices (line.column
>strings, w/ various optional modifiers) throughout.  Mark Hammond wrote a
>layer around PythonWin's text widget (currently Scintilla, IIRC) to
>translate its view of text indices to & from Tk's.  This layer also contains
>implementations for some Tk text commands, since they have to be spelled
>*somehow* and Tk's spellings seem as good as anything else (e.g., text.get()
>and text.delete() -- basic operations any text widget has to support).

Sure. As for text indices, I see two options to nicely solve it ("solve" as
in separate from Tk):
- the Idle Tk back end (huh-huh) gets modified to use (line, column) tuples
or
- see the indices as an opaque type, specific to the implementation, and
provide a standard interface that implements all neccesary text index math.

>if-tk-isn't-a-platform-python-isn't-a-language<wink>-ly y'rs  - tim

;-)

Thanks Tim!

Just