Update to reflect the current status of the configuration system.

Extensions must still be configured manually and there is currently one
set of extension key bindings for all platforms.

Bring NEWS.txt up to date.

Update CREDITS.txt and idlever.py for release.

M NEWS.txt
M config-extensions.def
M extend.txt
M help.txt
M idlever.py
This commit is contained in:
Kurt B. Kaiser 2003-07-16 03:10:43 +00:00
parent 21d9987cb5
commit cca912279a
6 changed files with 71 additions and 82 deletions

View File

@ -22,9 +22,9 @@ Other contributors include Raymond Hettinger, Tony Lownds (Mac integration),
Neal Norwitz (code check and clean-up), and Chui Tey (RPC integration, debugger
integration and persistent breakpoints).
Hernan Foffani, Christos Georgiou, Martin v. Löwis, Jason Orendorff, Noam
Raphael, Josh Robb, Nigel Rowe, and Bruce Sherwood have submitted useful
patches. Thanks, guys!
Scott David Daniels, Hernan Foffani, Christos Georgiou, Martin v. Löwis,
Jason Orendorff, Noam Raphael, Josh Robb, Nigel Rowe, and Bruce Sherwood have
submitted useful patches. Thanks, guys!
For additional details refer to NEWS.txt and Changelog.

View File

@ -1,7 +1,28 @@
What's New in IDLE 0.9b1+?
What's New in IDLE 1.0rc1?
===================================
*Release date: XX-XXX-2003*
*Release date: 17-Jul-2003*
- Updated extend.txt, help.txt, and config-extensions.def to correctly
reflect the current status of the configuration system. Python Bug 768469
- Fixed: Call Tip Trimming May Loop Forever. Python Patch 769142 (Daniels)
- Replaced apply(f, args, kwds) with f(*args, **kwargs) to improve performance
Python Patch 768187
- Break or continue statements outside a loop were causing IDLE crash
Python Bug 767794
- Convert Unicode strings from readline to IOBinding.encoding. Also set
sys.std{in|out|err}.encoding, for both the local and the subprocess case.
SF IDLEfork patch 682347.
What's New in IDLE 1.0b2?
===================================
*Release date: 29-Jun-2003*
- (Created the .../Lib/idlelib directory in the Python CVS, which is a clone of
IDLEfork modified to install in the Python environment. The code in the

View File

@ -1,5 +1,5 @@
# IDLE reads several config files to determine user preferences. This
# file is the default config file for idle extensions settings.
# file is the default configuration file for IDLE extensions settings.
#
# Each extension must have at least one section, named after the extension
# module. This section must contain an 'enable' item (=1 to enable the
@ -11,6 +11,10 @@
# present, ExtensionName_cfgBindings defines virtual event bindings for the
# extension that may be sensibly re-configured.
# Currently it is necessary to manually modify this file to change extension
# key bindings. Note: If a keybinding is already in use when the extension is
# loaded, the extension's virtual event's keybinding will be set to ''.
# See config-keys.def for notes on specifying keys.
[FormatParagraph]

View File

@ -1,4 +1,5 @@
Writing an IDLE extension
=========================
An IDLE extension can define new key bindings and menu entries for IDLE
edit windows. There is a simple mechanism to load extensions when IDLE
@ -7,10 +8,10 @@ to make other changes to IDLE, but this must be done by editing the IDLE
source code.)
The list of extensions loaded at startup time is configured by editing
the file config.txt; see below for details.
the file config-extensions.def. See below for details.
An IDLE extension is defined by a class. Methods of the class define
actions that are invoked by those bindings or menu entries. Class (or
actions that are invoked by event bindings or menu entries. Class (or
instance) variables define the bindings and menu additions; these are
automatically applied by IDLE when the extension is linked to an edit
window.
@ -26,41 +27,32 @@ variables:
(There are a few more, but they are rarely useful.)
The extension class must not bind key events. Rather, it must define
one or more virtual events, e.g. <<zoom-height>>, and corresponding
methods, e.g. zoom_height_event(), and have one or more class (or instance)
variables that define mappings between virtual events and key sequences,
e.g. <Alt-F2>. When the extension is loaded, these key sequences will
be bound to the corresponding virtual events, and the virtual events
will be bound to the corresponding methods. (This indirection is done
so that the key bindings can easily be changed, and so that other
sources of virtual events can exist, such as menu entries.)
The extension class must not directly bind Window Manager (e.g. X) events.
Rather, it must define one or more virtual events, e.g. <<zoom-height>>, and
corresponding methods, e.g. zoom_height_event(). The virtual events will be
bound to the corresponding methods, and Window Manager events can then be bound
to the virtual events. (This indirection is done so that the key bindings can
easily be changed, and so that other sources of virtual events can exist, such
as menu entries.)
The following class or instance variables are used to define key
bindings for virtual events:
An extension can define menu entries. This is done with a class or instance
variable named menudefs; it should be a list of pairs, where each pair is a
menu name (lowercase) and a list of menu entries. Each menu entry is either
None (to insert a separator entry) or a pair of strings (menu_label,
virtual_event). Here, menu_label is the label of the menu entry, and
virtual_event is the virtual event to be generated when the entry is selected.
An underscore in the menu label is removed; the character following the
underscore is displayed underlined, to indicate the shortcut character (for
Windows).
keydefs for all platforms
mac_keydefs for Macintosh
windows_keydefs for Windows
unix_keydefs for Unix (and other platforms)
At the moment, extensions cannot define whole new menus; they must define
entries in existing menus. Some menus are not present on some windows; such
entry definitions are then ignored, but key bindings are still applied. (This
should probably be refined in the future.)
Each of these variables, if it exists, must be a dictionary whose
keys are virtual events, and whose values are lists of key sequences.
An extension can define menu entries in a similar fashion. This is done
with a class or instance variable named menudefs; it should be a list of
pair, where each pair is a menu name (lowercase) and a list of menu
entries. Each menu entry is either None (to insert a separator entry) or
a pair of strings (menu_label, virtual_event). Here, menu_label is the
label of the menu entry, and virtual_event is the virtual event to be
generated when the entry is selected. An underscore in the menu label
is removed; the character following the underscore is displayed
underlined, to indicate the shortcut character (for Windows).
At the moment, extensions cannot define whole new menus; they must
define entries in existing menus. Some menus are not present on some
windows; such entry definitions are then ignored, but the key bindings
are still applied. (This should probably be refined in the future.)
Extensions are not required to define menu entries for all the events they
implement. (XXX KBK 15Jul03: But it appears they must have keybindings for each
virtual event?)
Here is a complete example example:
@ -73,48 +65,19 @@ class ZoomHeight:
])
]
windows_keydefs = {
'<<zoom-height>>': ['<Alt-F2>'],
}
unix_keydefs = {
'<<zoom-height>>': ['<Control-z><Control-z>'],
}
def __init__(self, editwin):
self.editwin = editwin
def zoom_height_event(self, event):
"...Do what you want here..."
The final piece of the puzzle is the file "config.txt", which is used
to to configure the loading of extensions. For each extension,
you must include a section in config.txt (or in any of the other
configuration files that are consulted at startup: config-unix.txt,
config-win.txt, or ~/.idle). A section is headed by the module name
in square brackets, e.g.
The final piece of the puzzle is the file "config-extensions.def", which is
used to to configure the loading of extensions and to establish key (or, more
generally, event) bindings to the virtual events defined in the extensions.
[ZoomHeight]
See the comments at the top of config-extensions.def for information. It's
currently necessary to manually modify that file to change IDLE's extension
loading or extension key bindings.
The section may be empty, or it may define configuration options for
the extension. (See ParenMatch.py for an example.) A special option
is 'enable': including
enable = 0
in a section disables that extension. More than one configuration
file may specify options for the same extension, so a user may disable
an extension that is loaded by default, or enable an extension that is
disabled by default.
Extensions can define key bindings and menu entries that reference
events they don't implement (including standard events); however this is
not recommended (and may be forbidden in the future).
Extensions are not required to define menu entries for all events they
implement.
Note: in order to change key bindings, you must currently edit the file
keydefs. It contains two dictionaries named and formatted like the
keydefs dictionaries described above, one for the Unix bindings and one
for the Windows bindings. In the future, a better mechanism will be
provided.
For further information on binding refer to the Tkinter Resources web page at
python.org and to the Tk Command "bind" man page.

View File

@ -153,15 +153,16 @@ Automatic indentation:
Python Shell window:
^C interrupts executing command
^D sends end-of-file; closes window if typed at >>> prompt
Control-c interrupts executing command
Control-d sends end-of-file; closes window if typed at >>> prompt
Command history:
Alt-p retrieves previous command matching what you have typed
Alt-n retrieves next
Return while on any previous command retrieves that command
Alt-/ (Expand word) is also useful here
(These are Control-p, Control-n on the Mac)
Return while cursor is on a previous command retrieves that command
Expand word is also useful to reduce typing
Syntax colors:

View File

@ -1 +1 @@
IDLE_VERSION = "1.0b2"
IDLE_VERSION = "1.0rc1"