+ Set usetabs=1. Editing pyclbr.py was driving me nuts <0.6 wink>.
usetabs=1 is the Emacs pymode default too, and thanks to indentwidth !=
tabwidth magical usetabs disabling, new files are still created with tabs
turned off. The only implication is that if you open a file whose first
indent is a single tab, IDLE will now magically use tabs for that file (and
set indentwidth to 8). Note that the whole scheme doesn't work right for
PythonWin, though, since Windows users typically set tabwidth to 4; Mark
probably has to hide the IDLE algorithm from them (which he already knows).
+ Changed comment_region_event to stick "##" in front of every line. The
"holes" previously left on blank lines were visually confusing (made it
needlessly hard to figure out what to uncomment later).
Smarter logic for finding a parse synch point.
Does a half to a fifth the work in normal cases; don't notice the speedup,
but makes more breathing room for other extensions.
Speeds terrible cases by at least a factor of 10. "Terrible" == e.g. you put
""" at the start of Tkinter.py, undo it, zoom to the bottom, and start
typing in code. Used to take about 8 seconds for ENTER to respond, now some
large fraction of a second. The new code gets indented correctly, despite
that it all remains "string colored" until the colorizer catches up (after
which, ENTER appears instantaneous again).
IDLE is now the first Python editor in the Universe not confused by my
doctest.py <wink>.
As threatened, this defines IDLE's is_char_in_string function as a
method of EditorWindow. You just need to define one similarly in
whatever it is you pass as editwin to AutoIndent; looking at the
EditorWindow.py part of the patch should make this clear.
stuff for getting the tip. Had to fix the Key-( and Key-) events
for Unix. Will have to re-apply my patch for catching KeyRelease and
ButtonRelease events.
Unix bindings for <<toggle-tabs>> and <<change-indentwidth>> were
missing, and somehow that meant the events were never generated,
even though they were in the menu. The new Unix bindings are now
the same as the Windows bindings (M-t and M-u).
The new version (attached) is fast enough all the time in every real module
I have <whew!>. You can make it slow by, e.g., creating an open list with
5,000 90-character identifiers (+ trailing comma) each on its own line, then
adding an item to the end -- but that still consumes less than a second on
my P5-166. Response time in real code appears instantaneous.
Fixed some bugs.
New feature: when hitting ENTER and the cursor is beyond the line's leading
indentation, whitespace is removed on both sides of the cursor; before
whitespace was removed only on the left; e.g., assuming the cursor is
between the comma and the space:
def something(arg1, arg2):
^ cursor to the left of here, and hit ENTER
arg2): # new line used to end up here
arg2): # but now lines up the way you expect
New hack: AutoIndent has grown a context_use_ps1 Boolean config option,
defaulting to 0 (false) and set to 1 (only) by PyShell. Reason: handling
the fancy stuff requires looking backward for a parsing synch point; ps1
lines are the only sensible thing to look for in a shell window, but are a
bad thing to look for in a file window (ps1 lines show up in my module
docstrings often). PythonWin's shell should set this true too.
Persistent problem: strings containing def/class can still screw things up
completely. No improvement. Simplest workaround is on the user's head, and
consists of inserting e.g.
def _(): pass
(or any other def/class) after the end of the multiline string that's
screwing them up. This is especially irksome because IDLE's syntax coloring
is *not* confused, so when this happens the colors don't match the
indentation behavior they see.
[Tim, after adding some bracket smarts to AutoIndent.py]
> ...
> What it can't possibly do without reparsing large gobs of text is
> suggest a reasonable indent level after you've *closed* a bracket
> left open on some previous line.
> ...
The attached can, and actually fast enough to use -- most of the time. The
code is tricky beyond belief to achieve that, but it works so far; e.g.,
return len(string.expandtabs(str[self.stmt_start :
^ indents to caret
i],
^ indents to caret
self.tabwidth)) + 1
^ indents to caret
It's about as smart as pymode now, wrt both bracket and backslash
continuation rules. It does require reparsing large gobs of text, and if it
happens to find something that looks like a "def" or "class" or sys.ps1
buried in a multiline string, but didn't suck up enough preceding text to
see the start of the string, it's completely hosed. I can't repair that --
it's just too slow to reparse from the start of the file all the time.
AutoIndent has grown a new num_context_lines tuple attribute that controls
how far to look back, and-- like other params --this could/should be made
user-overridable at startup and per-file on the fly.
One new file in the attached, PyParse.py. The LineStudier (whatever it was
called <wink>) class was removed from AutoIndent; PyParse subsumes its
functionality.
Removed "New tabwidth" menu binding.
Added "a tab means how many spaces?" dialog to block tabify and untabify. I
think prompting for this is good now: they're usually at-most-once-per-file
commands, and IDLE can't let them change tabwidth from the Tk default
anymore, so IDLE can no longer presume to have any idea what a tab means.
Irony: for the purpose of keeping comments aligned via tabs, Tk's
non-default approach is much nicer than the Emacs/Notepad/Codewright/vi/etc
approach.
2. No longer need to reset pyclbr cache and show watch cursor when calling
ClassBrowser -- the ClassBrowser takes care of pyclbr and the TreeWidget
takes care of the watch cursor.
3. Reset the focus to the current window after error message about class
browser on buffer without filename.
I'm still unsure, but couldn't stand the virtual event trickery so tried a
different sin (adding undo_block_start/stop methods to the Text instance in
EditorWindow.py). Like it or not, it's efficient and works <wink>. Better
idea?
Give the attached a whirl. Even if you hate the implementation, I think
you'll like the results. Think I caught all the "block edit" cmds,
including Format Paragraph, plus subtler ones involving smart indents and
backspacing.
[W]hile trying to dope out how redirection works, stumbled into two
possible glitches. In the first, it doesn't appear to make sense to try to
rename a command that's already been destroyed; in the second, the name
"previous" doesn't really bring to mind "ignore the previous value" <wink>.
You can switch database by just loading the new one; the list window
and nearest colors adapt to the new database.
Some reorganizing of code. Also, the name of the database file is
stored in the ~/.pynche pickle. If it can't be loaded, fallbacks are
used.
Ho ho ho -- that's trickier than it sounded! The colorizer is working with
"line.col" strings instead of Text marks, and the absolute coordinates of
the point of interest can change across the self.update call (voice of
baffled experience, when two quick backspaces no longer fooled it, but a
backspace followed by a quick ENTER did <wink>).
Anyway, the attached appears to do the trick. CPU usage goes way up when
typing quickly into a long triple-quoted string, but the latency is fine for
me (a relatively fast typist on a relatively slow machine). Most of the
changes here are left over from reducing the # of vrbl names to help me
reason about the logic better; I hope the code is a *little* easier to
there are two new commands:
Import module (F5) imports or reloads the module and also adds its
name to the __main__ namespace. This gets executed in the PyShell
window under control of its debug settings.
Run script (Control-F5) is similar but executes the contents of the
file directly in the __main__ namespace.
idle.py -e file ... -- to edit files
idle.py script arg ... -- to run a script
idle.py -c cmd arg ... -- to run a command
Other options, see also the usage message (also new!) for more details:
-d -- enable debugger
-s -- run $IDLESTARTUP or $PYTHONSTARTUP
-t title -- set Python Shell window's title
sys.argv is set accordingly, unless -e is used.
sys.path is absolutized, and all relevant paths are inserted into it.
Other changes:
- the environment in which commands are executed is now the __main__ module
- explicitly save sys.stdout etc., don't restore from sys.__stdout__
- new interpreter methods execsource(), execfile(), stuffsource()
- a few small nits
dramatically (up to 15 times he claims). Works by reading more than
one line at a time, up to 100-line chunks (starting with one line and
then doubling up to the limit). On a typical machine (e.g. Tim's
P5-166) this doesn't reduce interactive responsiveness in a noticeable
way.
unsuccessful search wraps around and re-searches that part of the file
between the start of the search and the end of the file - only really
an issue for very large files, but... (also removes a redundant
m.span() call).
o Makes the tab key intelligently insert spaces when appropriate (see Help
list banter twixt David Ascher and me; idea stolen from every other editor
on earth <wink>).
o newline_and_indent_event trims trailing whitespace on the old line (pymode
and Codewright).
o newline_and_indent_event no longer fooled by trailing whitespace or
comment after ":" (pymode, PTUI).
o newline_and_indent_event now reduces the new line's indentation after
return, break, continue, raise and pass stmts (pymode).
The last two are easy to fool in the presence of strings & continuations,
but pymode requires Emacs's high-powered C parsing functions to avoid that
in finite time.
I should have waited overnight <wink/sigh>. Nothing wrong with the one I
sent, but I couldn't resist going on to add new -r1 / -r2 cmdline options
for recreating the original files from ndiff's output. That's attached, if
you're game! Us Windows guys don't usually have a sed sitting around
<wink>.
Attached is a cleaned-up version of ndiff (added useful module
docstring, now echo'ed in case of cmd line mistake); added -q option
to suppress initial file identification lines; + other minor cleanups,
& a slightly faster match engine.
Unfortunately his code breaks wcgui.py in a way that's not easy
to fix. I expect that this is a temporary situation --
eventually Sam's changes will be merged back in.
(The changes add a -t option to specify exceptions to the -x
option, and explicit checking for #foo style fragment ids.)
the ob_itself pointer. This allows (when using the mixin)
different Python objects pointing to the same C object and
behaving well as dictionary keys.
Or so sez Jack Jansen...
Under Windows, python freeze.py -o hello hello.py
creates all the correct files in the hello subdirectory, but the
Makefile has the directory prefix in it for frozen_extensions.c
nmake fails because it tries to locate hello/frozen_extensions.c
(His fix adds a call to os.path.basename() in the appropriate place.)
pyclbr.Class object; this can happen when the superclass is
unrecognizable (to pyclbr), e.g. when module renaming is used.
- Show a watch cursor when calling pyclbr (since it may take a while
recursively parsing imported modules!).
directories on sys.path
modules in selected directory
classes in selected module
methods of selected class
Sinlge clicking in a directory, module or class item updates the next
column with info about the selected item. Double clicking in a
module, class or method item opens the file (and selects the clicked
item if it is a class or method).
I guess eventually I should be using a tree widget for this, but the
ones I've seen don't work well enough, so for now I use the old
Smalltalk or NeXT style multi-column hierarchical browser.
with changed APIs -- it makes much more sense there.
Also add a new feature: if the first character of a menu label is
a '!', it gets a checkbox. Checkboxes are bound to Boolean Tcl variables
that can be accessed through the new getvar/setvar/getrawvar API;
the variable is named after the event to which the menu is bound.
The separator dances too much and seems to jump by arbitrary amounts
in arbitrary directions when I try to move it for resizing the frames.
This patch makes it more quiet.
Much has changed -- too much, in fact, to write down.
The big news is that there's a standard way to write IDLE extensions;
see extend.txt. Some sample extensions have been provided, and
some existing code has been converted to extensions. Probably the
biggest new user feature is a new search dialog with more options,
search and replace, and even search in files (grep).
This is exactly as downloaded from my laptop after returning
from the holidays -- it hasn't even been tested on Unix yet.
to color constants (i.e. red constant, green constant, blue
constant). But I haven't hooked this up yet because the UI gets more
crowded and the arrows don't reflect the correct values.
Added "Go to Black" and "Go to White" buttons.
show(): added color keyword here so that the selected color can be
chosen on each invocation of askcolor().
Also fixed this class, and askcolor() so that the same Chooser
instance can be re-used instead of creating a new one on each
invocation of askcolor().
Added a module function save() which can be used to explicitly save
the option database in ~/.pynche. This does not happen automatically
when used as a modal.
run either as a standalone application (by running pynche or
pynche.pyw), or as a modal dialog inside another application. This
can be done by importing pyColorChooser and running askcolor(). The
API for this is the same as the tkColorChooser.askcolor() API, namely:
When `Okay' is hit, askcolor() returns ((r, g, b), "name"). When
`Cancel' is hit, askcolor() returns (None, None).
Note the following differences:
1. pyColorChooser.askcolor() takes an optional keyword `master'
which if set tells Pynche to run as a modal dialog. `master'
is a Tkinter parent window. Without the `master' keyword
Pynche runs standalone.
2. in pyColorChooser.askcolor() will return a Tk/X11 color name as
"name" if there is an exact match, otherwise it will return a
color spec, e.g. "#rrggbb". tkColorChooser can't return a
color name.
There are also some UI differences when running standalone vs. modal.
When modal, there is no "File" menu, but instead there are "Okay" and
"Cancel" buttons.
The implementation of all this is a bit of a hack, but it seems to
work moderately well. I'm not guaranteeing the pyColorChooser.Chooser
class has the same semantics as the tkColorChooser.Chooser class.
"""
the NEWS file of Python 1.5.2a2 inspired me to look at
Tools/scripts/untabify.py. I wonder why it accepts a -t argument
but ignores it. The following patch tries to make it somewhat useful
(i.e., to override the tabsize=8 setting). Is that agreeable?
"""
priority over text colorization (which on Windows is almost the
same color as the selection background).
Define a tag and color for breakpoints ("BREAK").
Guido van Rossum
Barry Warsaw
Fred Drake
Andrew M. Kuchling